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SECTION 1 

INTRODUCTION AND SUMMARY 

The traditional approach to processing data from spaceborne sensors in ground facilities has proven inade- 
quate to satisfy even today's requirements in terms of quantity, quality, and timeliness,, The data received 
on the ground is raw; it must undergo various processes to render it useable to the experimenter. These 
range from simple reformatting to complex domain transformation and information extraction processes 
which are usually accompanied by correlations with time, ephemerides, and other ancillary data which are 
resident in exogeneous sources. Data is collected rapidly and simultaneously by many sensors but must 
wait in line to be processed by centers characterised by limited throughput and high cost. 

The Space Shuttle can accommodate 10, 000 cubic feet of experiments. It will fly, on the average, twenty- 
five times per year in the 1980’s, and technology will have increased manyfold the experimenter’s capabil- 
ity to generate data. Tb" magnitude of the data processing requirements in the Shuttle Era will far exceed 
the capabilities of any conceivable system designed and operated using today’s methods. We need a new 
approach. 

This approach must creatively exploit the same advanced technology used by those who generate data. The 
large capacity of the Shuttle, which can cause the data avalanche, also offers the capability to install a sig- 
nificant portion of a new type of end-to-end processing system onboard, permitting the use of this technology 
to process data in totally new ways at the data source. 

The Onboard Experiment Data Support Facility (OEDSF) has been conceived and designed to fulfill this 
need. The OEDSF is a totally new approach specifically formulated to process the science data of multiple 
instruments. Its design directly evolves from analyses of the data processing requirements of over 70 
instruments constituting shuttle payloads. Figure 1-1 depicts the OEDSF concept and iis role in the shuttle 
data processing. Each array 1 b a distributed set of elements performing medium level functions: A is an 
arithmetic element performing the expression + Z and all its subsets. T performs all forward and 
inverse trigonometric functions. E performs all exponential and logarithmic functions. 

The array constitutes sets of programmable pipeline processors whose elements perform each assigned 
function in 0.25 microseconds. Its characteristics are summarized in Table 1-1. 

It can handle data rates from a few bits to ever 100 megabits per second. 
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Figure 1-1. The OEDSF Concept 


Table 1-1. OEDSF Characteristics 



FEATURES 

ATTRIBUTES 

« 20 SENSORS AVERAGE PER ARRAY 

b SIX POINT ARCHITECTURE 

e REALTIME PROCESSING 

e 5X 5MATRIX CPU 

o ASYNCHRONOUS INPUT/OUTPUT 

a HIEARCHIALMEMORY STRUCTURE 

e 250 NANOSECOND MACHINE CYCLE 

« CENTRAL LIBRARY 

e 28, 494 AVAILABLE PIPELINES 

• THREE GENERIC PROCESSING ELEMENTS 

n 100 MEGA FUNCTIONS PER SECOND 

a PROGRAMMABLE PIPELINES 

s MODULAR AND CASCADABLE 

8 WIDE BANDWIDTH 



Each array occupies one cubic foot, draws 150 watts, and costs approximately $636K*. Its cost effective- 
ness is demonstrated in Table 1-2 which compares the cost of onboard processing with the cost of conven- 
tional ground equipments performing the identical processes for sample instruments. 


* Average cost of development and eight production units. 
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Table 1-2 . Effectiveness Analysis Summary 








CONVENTIONAL APPROACH 



DATA IMMEDI- 
ATELY AVAIL- 
ABLE ON (NDDT) 

DATA 

COMPRESSION 

RATIO 

ANCILLARY 

DATA 

GROUND 

PROCESSING 

ELIMINATED 

GROUND 

PROCESSING 

ADDED 

TIME 

cost per 

MISSION 

SK 

COST OF OEDSF 
SYSTEM 
SK 

ATS 

CORRECTED 
DIGITAL 
IMAGERY WITH 
LAT AND LON 

NONE 

ELIMINATED 

CALIBRATION 
RADIOMETRIC 
AND GEOMETRIC 
CORRECTION 

NONE 

6 TIMES REAL 
TIME 

2646 

163.9 

IRS 

RAW TEMPERA- 
TURE AND 
MIXING RATIO 
PROFILES WITH 
LAT AND LON 
PER GRID 

16.1 

ELIMINATED 

calibration 

CALCULATION 
OF TEMP AND 
MIXING RATIO 

FLAG CHECK 

1/B REAL TIME 
WITH 24 HOURS 
DELAY 

306 

18,4 

RADSCAT 

ua AND Ta WITH 
LAT AND LON 

90.1 

ELIMINATED 

CALIBRATION 
CALCULATION 
OF at, AND Ta 

NONE 

35 TIMES 
REAL TIME 

b7? 

17.7 

C| MATS 

SPECIE CONCEN- 
TRATION WITH 
LAT, LON, AND 
ALTITUDE 

20, 1 

ELIMINATED 

ALL 

NONE 

TBD 

432 

17.9 


The elements of the QEDSF have been designed and breadboarded on a General Electric Independent 
Research and Development Program, The results of this program are reflected in the specific design 
approaches described in this report. 

The OEDSF concept embodies on off-line computer program which converts the set of processes required 
for each sensor supplied in a user-oriented high level language to the microcode used onboard by the OEDSF. 
The $950K development cost of this program is included, on a pro-rated basis, in the costs of Table 1-2. 

The cost advantages of a central facility over a set of dedicated processors are depicted in Figure 1-2 
which plots relative cost (in terms of the number of Integrated Circuits, or an equivalent Number of Instruc- 
tions for a software approach) against the number of sensors serviced. 

Composite sensor B is a hypothetical sensor representing the average sensor in a typical shuttle payload. 
The OEDSF is cost effective when the number of even lower complexity sensors exceeds a quantity of 8 to 
10, Additionally, the OEDSF is designed to be inexpensively reconfigured for totally different sets of 
sensors whereas dedicated costs continue to be linearly related to the number of new sensors. 
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Figure 1-2. Cost of Centralized OEDSF vs Dedicated Processors 

The OEDSF is packaged in a modular configuration which provides a totally self-contained array and readily 
enables expansion to multiple array systems as depicted in Figure 1-3. 

An alternate package design provides cooling by attachment to cold plates and obviates the need for cooling 
fans and atmosphere. 

The OEDSF' s greatest benefit resides in its real-time processing of the data. This results in the informa- 
tion being immediately useable by the experimenter. It also enables the synergistic operation of multiple 
instruments whereby the data of one is processed using the data of another. (For example, the data of an 
infrared spectrometer corrects that of a scanning radiometer to account for atmospheric effects.) 

Many processes are based on ancillary information such as vehicle attitude, ephemerides, ambient condi- 
tions, and look angles. The OEDSF performs these processes using this information in its real-time form 
and obviates the need for time-tagging, recording, and subsequent recorrelation with the science data. 

The OEDSF embodies growth potential in its strong candidacy for implementation with Large Scale Integra- 
tion (LSI) circuits, Near-term technology will enable the fabrication of each processing element of the 
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Figure 1-3. OEDSF Mechanical Packaging 


OEDSF on a single integrated circuit chip. This will result in a complete array contained on a single board 
The low-production cost of such an array will justify the dedication of a complete array to each Instrument 
despite the extremely low level of utilization of its capability. This concept reverses the results of the 
trade-offs summarized in Figure 1-2. 

The study followed the flow plan shown in Figure 1 4. 
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Figure 1-4. Study Flow Plan 


REPRODUCIBILITY OF THE 
♦JUGfNAL PAGE IS POOR 





The od: actives of the OEDSF Study summarized in Figure 1-5, have been met 


DEFINE AN END-TO-END PROCESSING APPROACH WHICH RESULTS IN LOWER TOTAL 
PROGRAM COSTS, MORE RAPID OUTPUT OF STS EXPERIMENT DATA TO USERS, AND 
MORE EFFECTIVE DATA PRODUCT FORMATS AND CONTENT OF DATA PRODUCTS. 


DEFINE A CONCEPTUAL DESIGN AND SPECIFICATION FOR AN STS ONBOARD 
PROCESSOR WHICH IS COMPATIBLE WITH THE ABOVE APPROACHES. 


ANALYZE THE CONCEPTUAL DESIGN TO DETERMINE THE DEGREE OF COMPLIANCE 
TO THE ACHIEVEMENT Of OEDSF OBJECTIVES. 


Figure 1-5. OEDSF Study Objectives 








CONCLUSIONS 


• There are significant benefits to be derived from onboard processing. These include: 

~ Timely availability of data to user 

— Lower costs compared to conventional processing approaches 

— Real-time utilization of ancillary information 

— Reduction in the quantity of data transmitted and stored,, 

6 The concept of a processor based on a set of programmable pipeline processor responds to all the 
requirements of a data processor onboard the shuttle. These include: 

— Cost-effectivity 

— Multiple sensor complements from multiple disciplines 

— Combinations of very low and very high data rates 

— Real-time processing 

o The level and extent of processing performed onboard that is beneficial or desired by the user is 
dependent on the class of user. Most, however, benefit from performing those processes which use ancil- 
lary data. 


REPORT ORGANIZATION 


This report is organized as follows: 

Section 1 is the introduction and summary. 

Section 2 describes the methodology of the study: The selection of boundary sensors, the determination of 
their processing requirements, the partitioning of the required processes between onboard and ground seg- 
ments, the conception of the architecture for the onboard processor, the design of the processor, and the 
analyses of its effectiveness. 


Section 3 discusses the selection of the Boundary Sensors: The tabulation of candidate shuttle instruments, 
generation of selection criteria, selection and justification of the boundary sensors. 
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Section 4 derives the processing requirements of the boundary sensors in a real time mode anti the resulting 
requirements on the OEDSF, 

Section 5 aynthetizes a hypothetical instrument based on the average rate and processing requirements of 
the set of sensors examined in Section 3 as related to the boundary sensors. This instrument provides a 
more generalized set of requirements than the boundary sensors and enables the extrapolation of the results 
based on the boundary sensors to full payloads. 

Section 6 examines various processing system architectures suitable for the OEDSF. The array (or matrix) 
concept is evolvad and traded-off against more conventional approaches. 

Section 7 describes the entire conceptual design of the OEDSF. The major elements discussed include the 
Central Processing Unit (CPU), the asynchronous Input/Output concepts, the Data Base design, the Bus 
structure, the Control structure, and the mechanical and thermal considerations. 

Section 8 describes the Index Generating Program. This major software element is key to the achievement 
of relegating the effort of programming the OEDSF for multiple sensor payloads on each mission to a trivial 
and inexpensive task. 

Section 9 discusses the effectiveness of the OEDSF in terms of both functional performance and costs. The 
advantages of onboard processing are described and the costs of performing processes onboard with the 
OEDSF are compared to those for performing the identical processes using conventional methods. Users 
are identified and the benefits they derive from onboard processing are defined. This section also analyzes 
the alternatives available to provide OEDSF simulation to the experimenters during levels IV and V integra- 
tion with their experiments. 

Section 10 examines the aspects of the OEDSF related to Reliability, Quality Assurance and Safety. 

Section 11 is the development plan for the OEDSF. It presents a prop sed schedule tailored to the antici- 
pated start date of the hardware program and the scheduled date for target shuttle flights, a work breakdown 
structure, and a work package description. 

Appendix A is an evaluation of the present state-of-the-art and a forecast in the technologies applicable to 
the OEDSF. 

Appendix B are a set of benchmark programs used in trade-offs between hardware and software implementa- 
tion of various segments of the OEDSF CPU. 
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Appendix C describes a polynomial generator which is sn alternate to the different processing elements of 
the CPU and was used in the CPU elements trade-off analyses. 


Appendix D is the Design and Requirements Summary fov the OEDSF 


SECTION 2 

STUDY METHODOLOGY 


The design of the OEDSF was developed by a point-design approach; I. e. , designing to satisfy specific 
requirements, then broadening these requirements to encompass a more general set. 

The study was divided into four tasks which formed a logical flow beginning with an analysis of sensors and 
their prooessing requirements and culminating in the design of a processor satisfying these requirements 
onboard in a cost effective approach. The flow of the study is depicted in Figure 2-1. 

A set of over 150 instruments was culled to select 77 experiments which are candidates for flight on the 
shuttle. 

A limited set of these experiments were selected as ’’boundary" experiments because they satisfied the 
selection criteria which imposed "tail-pole" and "representativeness" conditions on the data processing re- 
quirements. The processing requirements for these selected boundary experiments were then defined. 
Figure 2-2 summarizes the results of this effort. 
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Figure 2-2. Taak I Summary 


The processing requirements of the boundary sensors were then converted to real-time processes because 
onboard processing implies exploitation of tbe real-time availability of ancillary data. Criteria were 
developed for processes which would benefit from onboard processing and applied to the set of processes 
required by the boundary sensors. 


The set of requirement assigned to on-board processing define the requirements on tbe OEDSF. Decom- 
position of the on-board processes yielded the basic requirements for the capability of the OEDSF. The 
Levels of decomposition weighted by the considerations of the goals of handling multiple sensors on 
repeated flights at data rates ranging from tens of bits per second to hundreds of megabits per second 
were used to define a suitable architecture. 


These efforts are depicted in Figure 2-3, 

The selected onboard processor architecture was then developed into a complete conceptual design 
oriented toward the cost effective processing of shuttle sensor payloads. The specific areaB of analysis 
included the Central Processing Unit, the interfaces with sensors and spacelab equipments, the structure 
control, the data base, and the bus structure. The design of the processor was an iterative process which 
continuously evaluated the impact of the design on tbe satisfaction of the OEDSF goals and objectives. This 
process is depicted in Figure 2-4. 

The initial design was specifically aimed at satisfying the requirements of the boundary sensors and was 
then evaluated on its capability to process randomly selected sensors. 

The OEDSF was ther evaluated in terms of its benefits. These include technical benefits such as increased 
accuracy and improved timeliness, and cost benefits. The costs of processing data on-board with the 
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OEDSF were determined using the cost of producing the OEDSF, those of flying it on the shuttle, and those 
associated with its concept including the costs of integration. 

These were compared with the costs associated with conventional ground equipments using the boundary 
sensors as samples. These cost comparisons were then extended to full shuttle payloads. 

As a final product of the study a development plan was evolved. This plan provides a schedule which pro- 
duces an OEDSF flight model within the time frame anticipated from authorization to target shuttle flights, 
a Work Breakdown Structure which was also used in deriving the cost of producing an OEDSF, and a Work 
Package Description defining the efforts identified in the Work Breakdown Structure. 
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SECTION 3 

BOUNDARY SENSORS SELECTION 


The methodology of the study depended on point designs performed on selected instruments. These instru- 
ments are termed "boundary” sensors and are characterised by features which are extremes of their do- 
main or by a high degree of representativeness. 

77 instruments were identified as candidate boundary sensors and tabulated with the features of interest in 
data processing to enable selection, as exemplified by Table 3-1. The complete set of tabulations is con- 
tained in the OEDSF Task 1 report. 

The criteria for the selection of these boundary sensors are discussed below. 

CRITERIA FOR SELECTION OF BOUNDARY EXPERIMENTS 

1. Data Rates and Data Storage: Experiments which represent a \arge range of data rates should be 
chosen. Such a selection will provide several boundary points In terms of the data processing 
whidh can or must he considered In designing a processing system. For example, instruments 
with data rates less than 500 kbps represent e;cperiments for which considerable on-board pro- 
cessing such as formatting, application of calibration data, and partial or complete data reduction 
can be accomplished. Data rates greater than 50 mbps, on the other hand, may require the appli- 
cation of various data compression techniques and partial pre-processing to reduce the total accu- 
mulated volume of data to a level which can be practically recorded or transmitted. 

OyernU Processing Requirements: The end-to-end processing requirements should involve a level 
of complexity which will truly benefit from the features offered by on-board processing. When the 
end^%-end processing requirements of a particular experiment are viewed. It will be apparent that 
certain processing functions can be performed on-board. Typical candidate processing functions 
include complex correction techniques, correlation of several parameters, inversions or lengthy 
iterative calculations. If the end products of the experiment can be obtained more efficiently (l.e. , 
quicker, less cost, etc. ) by performing such on-board processing then the experiment will serve 
as a good boundary experiment. 

3. Representativeness: The data and its processing requirements should be characteristic or repre- 
sentative of that from many experiments. By considering the point by point processing require- 
ments of these specific experiment* <e. g. , radiometric calibration and correction, geometric 
correction, data quality assessment, etc. ) generalized processing algorithms can be designed to 



Table 3-1. Sample of Sensor Tabulations 


Interaction 


Experiment 

#b 

Gas Plume 
Release 

Science Data. 
Form Rate 

MeaGurcmcnt 

Period 

Ancillary 

Data 

Required 

On- 

Board 

Displays 

Required 

With Other 
Instruments 
Possible (P) 
oi Req'd (R) 

Data 

Processing 

Requirements 

Objective 

or 

End Product 

Unusual 
Requirements 
and Comments 

TV 

4.5 

Mhz 

Maximum of 4 hrs. 
per day, concurrent 
with accelerator 
operation. 

N/A 

Replay of 
Beveral 
secs of TV 
from 

video tape. 

Operates in 
conjunction 
with electron 
Ei ion accel- 
erators 

Little process- 
ing req'd. Data 
consists of op- 
tical observa- 
tions of plume 
release. 

Video tape of gas 
release. 

Controls of accelera- 
tors must be coord- 
inated with gas re- 
lease Bt video taping. 

t)7 Fyroheiio- 
meter It Spec- 
trophotometer 

D 

3 20 
BPS 

2 or 3 scans per 
daylight half-orbit. 
10 minutes per scan. 

Pointing 
angle re- 
la ive to 
the sun. 
Tempera- 
ture and 
ephsmeris 
data. 

Lights to 
show when 
various con- 
trols are 
activated. 

Simultaneous 
measurement 
of earth's al- 
bedo with 
second instru- 
ment (PJ. 

Bore sight 
with sun- 
traeker (R). 

Simple corre- 
lation between 
instruments 
fc with ancil- 
lary data. 

Low level 

processing 

requirements. 

Value of solar con- 
stant and solar 
spectral irrad- 
iance. 


#8 Optical 
band image 
(i photometer 
system 

TV 

2 

units 

D 

Photo 

meter 

4 

Whr 

each 

40 

KBPS 

Determined by 
phenomena to be 
measured. 

Ephomeris 
data; at- 
titude to 
0. 02°; time 
of middle of 
TV picture 
to .003 sec. 

One video 
TV moni- 
tor it var- 
ious indi- 
cator 
lights 

None {R} 

Basic output 
is intensity at 
at preselected 
wavelengths . 
Quantity fc mix 
of data types 
present a data 
mp>mt, problem. 

Monochromatic 
images of faint 
natural phen- 
omena, e. g. , 
auroras (nat- 
ural 6 arti- 
ficial), glows, 
etc,. 

Direction of photo- 
meters controlled by 
crew, based on TV 
images. 

#9 Infrared 
Interfero- 
meter 

D 

1000 

BPS 

3 minutes per data 
take; up to 3 data 
takes during a 
given orbit. 

Ephomeris 
data; pointing 
of instrument 
with acc. 
a 0.1°. 

TBD 

None (R) 

Basic output is 
intensity vs. 
wavelength. 
Requires cali- 
bration data 
to correct 
tneas. 

Special analysis 

at IR wavelengths 
(Specific use TBD) 


#10 

Limb 

Scanning 

Infrared 

Radiometer 

D 

12 

KBPS 

Operates from dark 
side of the termina- 
tor; one data take 
may be up to 5 min. 

Ephemeris 

data. 

Relative 

pointing 

angle. 

Detector 

temp. 

Display for 
crew eval- 
uation of 
instrument 
status & 
data from 
4-12 spec- 
tral chs, 

None (R) 

Basic output is 
intensity vs. 
wvlgth.Req. 
calibr.data. 

Spectrum com- 
pared with kwn, 
spectra to ident. 
trace gase3. 

Measurement of 
trace, species at 
altitudes up to 
120 Kin. 


#11 Magnoto- 
p lasma - dyn am - 
1c (MPD) arc 
(Level I Diag- 
nostics) 

A 

X 

Mhs 

Approx. 4 hours 
per day 

Ephemeris 

data. 

Ambient 

plasma 

densities 

CRT display 
of pulse 
wave forms 
it several 
heusekeep. 
parameters 

Operates with 
mass spectro- 
meters, ion 
mass analy- 
zers, TV, 
etc. MPD 
axe is a sub- 
system of 
particle 

Many inter- 
acting inputs. 
Requires sub- 
tract. of ex- 
traneous fields 
which may in- 
volve complex 
algorithms. 
Real time data 

Map of ear til's 
magnetic field 
lines. Effect of 
p e r( orbing ■ iono - 
sphere conduct- 
ivity it genera- 
tion of plasma 

waves. 

Requires rapid 
digitization of 
pulse wave forms. 


ace el. system display req'd. 


handle the boundary experiments as well as all experiments which require the same or similar 
processing functions. Also, an experiment which by itself or when used in consort with other 
experiments requires the processing and correlation of several types of data (e.g., digital, analog, 
video, etc.) provides the requirements for designing a more versatile data support system. 

4. On-Board Processing: An experiment should have the potential for benefiting from on-board pro- 
cessing. One of the prime objectives of the OEDSF is to exploit the real-time availability of an- 
cillary data or the real-time utilization of other instrument data to perform on-board processing 
which will minimize the amount and diversity of the data which must be transmitted or returned to 
earth. Such on-board pre-processing or processing of the data should have a significant impact on 
the ©nd-to-and processing: cost, timeliness, or quality. 

5. Real-Time Requirements: Certain experiments require or desire real-time processing either for 
quick look and evaluation of instrument operation, or to use the data in adjunct experiments. The 
real-time requirements must be considered as one of the ,r points" in the point-by-point design of a 
processing system. While usually not a driving parameter in the overall design, the real-time 
needs render the experiment a prime candidate for selection if it also meets other boundary criteria. 

6. Status of Experiment Development: The experiment should be developed to the state where it is 
possible to characterize its data output and define its data processing requirements. It will then 
be possible to do a point-by-point design of a processor for the selected experiments followed by a 
generalization of the design to be compatible with several experiments having the same basic 
requirements. 

An additional consideration not explicitly stated as a criterion was to obtain a mix of various re- 
quirements and technologies, i.e., active, passive, spectral coverage (visual, microwave). 

The instruments selected are indicated in Table 8.2 together with the reason for selection and the potential 
benefits of onboard processing. The reasons for their selection is amplified in the following paragraphs. 

1. Advanced Technology Scanner (ATS) 

The data and processing from the ATS is typical of imaging visible/lR spectrum sensors. The 
output consists of digital words representing radiance values for specific spectral intervals and 
geodetic locations. This raw data is "in error", and must have both radiometric and geometric 
corrections applied. Such corrections can be performed most efficiently on-board by utilizing real- 
time calibration Input parameters. In addition, the very high data rate (-90 mbps) points out the 
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Table 3-2. Boundary Experiments 


EXPERIMENT 


ADVANCED 

TECHNOLOGY 

SCANNER 

(ATS! 


CORRELATION 
INTERFEROMETER 
MEASUREMENTS 
OF ATMOSPHERIC 
TRACE SPECIES 
(CIMATS) 


INFRARED 

SPECTROMETER 

(IRS) 


ELECTRON 

ACCELERATOR 


MICROWAVE 

RADIOMETER/ 

SCATTEROMETER 

(RADSCAT) 


OPTICAL BAND 
IMAGE AND 
PHOTOMETER 
SYSTEM 
(OBIPS) 


REASON FOR SELECTION 

POTENTIAL BENEFITS OF 
■ ONBOARD PROCESSING 

DATA AND PROCESSING IS TYPICAL OF IMAGING 
VISIBLE/IR SPECTRUM SENSORS. VERY HIGH DATA 
RATE (~90 MBPS). RELATIVELY COMPLEX PRO- 
CESSING, SOME OF WHICH IS MORE EFFECTIVELY 
DONE ON-BOARD. 

DATA TOTALLY PREPROCESSED/ 
CORRECTED. READY FOR 
INFORMATION EXTRACTION- 
DATA IMMEDIATELY USEFUL TO 
RESOURCE MANAGER USER 

EXAMPLE OF DATA FROM A BROAD CATEGORY OF 
INTERFEROMETERS. REQUIRES LIMB INVERSION 
AND ITERATIVE CALCULATIONS. REQUIRES 3-4 MB 
STORAGE PER ORBIT. 

TOTALLY PROCESSED DATA REDUCES 
STORAGE REQUIREMENTS FROM 
> 100 BITS TO TABULATIONS 
ELIMINATES NEED FOR ANCILLARY DATA 
AND CORRELATION WITH SCIENCE DATA 

RELATiVELY LOW BIT RATE (3.4 KBPS). PERMITS 
EXTENSIVE REAL-TIME ON BOARD PROCESSING. 
REDUCED DATA CAN BE USED IN REAL TIME BY 
OTHER SENSORS AS AUXILIARY CORRECTION DATA: 

PREPROCESSING CAN 
SIGNIFICANTLY REDUCE COMPLEXITY 
OF GROUND PROCESSING WHICH 
PRESENTLY UTILIZES LARGE COMPUTERS 
FOR EXTENDED TIME PERIODS 


COMPLEX DISPLAY AND STORAGE REQUIREMENTS ENABLES REAL-TIME CONTROL 

(ANALYSIS AND CRT DISPLAY OF 100 NS PULSE AND INTERACTION WITH OPERATOR. 

SHAPES). REQUIRES FAST DIGITIZATION OF REDUCTION OF STORAGE OF 

ANALOG DATA. REQUIRES INTERACTION WITH HIGH DATA RATE AND 

OTHER INSTRUMENTS. ANCILLARY DATA. 


PROCESSING REQUIRES COMPLEX UTILIZATION OF 
ANCILLARY DATA WHICH IS AVAILABLE ON BOARD IN 
REAL-TIME. EXPLOITATION OF THIS AVAI LABILITY TO 
CALCULATE RADAR BACKSCATTER CROSS-SECTIONS 
WILL SIGNIFICANTLY REDUCE THE QUANTITY OF DATA 
RETURNED TO GROUND AND GREATLY REDUCE THE 
TIME REQUIRED FOR END-TO-END PROCESSING. 


ELIMINATION OF LARGE 
QUANTITIES OF ANCILLARY 
DATA AND TIME CONSUMING 
RE-CORRELATION ON GROUND. 
DATA IMMEDIATELY USEFUL 
TO EXPERIMENTER. 


BOT'I TV AND DIGITAL DATA AS OUTPUTS. REQUIRES ELIMINATION OF USELESS OATA 

HIGH DEGREE OF CREW INTERFACE (ON-BOARD REAL WHICH MAY CONSTITUTE UP 

TIME TV DISPLAY). HIGHLY ACCURATE ATTITUDE TO 95% OF DATA COLLECTED 

AND TIMING DATA MUST BE CORRELATED WITH AT 8MHZ RATE. 

SCIENCE DATA BY INSERTION INTO THE VIDEO VIA A 
CHARACTER GENERATOR (THIS MAY BE A GENERAL 
REQUIREMENT FOR ALL VIDEO EXPERIMENTS). LARGE 
PERCENTAGE OF TV DATA CONTAINS NO INFORMATION 
AND CAN BE EDITED OUT OF MAIN DATA STREAM 
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need for such processing, together- with some type of on-hoard data quality assessment to insure 
that only useable data is recorded or transmitted for complete analysis. 

Infrared Spectrometer (IRS) 

Nearly identical versions of the IRS experiment have been down previously so that its data pro- 
cessing requirements are well defined. Radiance calibration and angular corrections can be per- 
formed efficiently on-board utilizing the availability of real-time ancillary data. Analysis of the 
corrected raw data can he performed on-board to the extent necessary for use by other sensors as 
auxiliary correction data. The end-to-end processing involves inversion of the radiative transfer 
equation and evaluation of the iterative solution of die water vapor equation. 

Correlation Interferometer Measurements of Atmospheric Trace Species (CIMATS) 

The data from the CIMATS experiment is representative of a broad category of interferometers. 
The low bit rate (~3 kbps) will permit extensive on-board processing. Real-time ancillary data, 
together with a data bank of correlation functions can be used to perform the necessary corrections 
on the raw data and carry the required processing to the end product. Processing of the corrected 
data will require limb inversion and iterative calculations (e.g. , solution of 10 equations in 10 
unknowns). 

Microwave Radiometer/Scatterometer 

Processing of the Microwave Radiometer/Scatterometer data requires complex utilization of 
ancillary data which is available on-board in real-time. Exploitation of this availability to calcu- 
late radar backsoatter cross-sections will significantly reduce the quantity of data returned to 
ground and greatly reduce the time required for end-to-end processing. In addition, real-time 
processing is desired to determine trend analyses of raw data (such as means and standard devia- 
tions) to provide a rapid indication of proper instrument operation. 

Electron Accelerator 

The electron accelerator must be used in consort with various d jctors. Consequently, precise 
timing between the accelerator operation and the detecting instruments is required. Real time data 
displays and preliminary processing will be needed to seleci the accelerator program (i.e,, pulse 
duration, pulse repetition rate, beam injection angle, etc.). Capability for storage ar.d recall of 
pulse shapes of several rapidly varying parameters, which must be correlated in time, will be re- 
quired. This may necessitate the use of fast digitizers with selectable sampling frequencies of up 
to 100 MHz. 


6. Opt' ;al Band Image and Photometer System (QBJPS) 

The experiment consists of three subsystems which have both TV and digital data as outputs. A 
large percentage of the TV data contains no information and can be edited out of the main data 
stream, thereby reducing the telemetry or recording requirements. Highly accurate attitude and 
timing data must be correlated with the science data by insertion into the video via a character 
generator. Additional housekeeping data is inserted in the vertical interval (i.e. , during the verti- 
cal retrace). This method of inserting ancillary data into the science data may be a general re- 
quirement or desired capability for all vide ^ experiments. 

Figure 3-1 summarizes the degree of representativeness achieved by this selection in the four 
domains of interest. 

Figures 3-2 through 3-7 summarize the data processing f ceps required for each of the boundary 
sensors. 

Following the completion of Task 1, the OBIPS and the Electron Accelerator were dropped from 
the list of boundary sensors because their processing requirements were not defined sufficiently 
to allow fruitful results in Task 2. 
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Figure 3-1. Representativeness 


a- . 





FILM 

CAMERA 



SENSOR OUTPUT 
90 MbPS 


EPHEMERIDE 

AND 

ATTITUDE ATMOSPHERIC 

DATA DATA 



Figure 3-2. Advanced Technology Scanner Data Processing Flow Diagram 
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Figure 3-3. Infrared Spectrometer Data Processing Flow Diagram 
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Figure 3-4. Radiometer/Scatterometer Data Processing Flow Diagram 
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Figure 3-5. CEMATS Data Processing Flow Diagram 
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Figure 3-6. 


Electron Accelerator Data Processing Flow Diagram 



Figure 3-7. Optical Band Imager and Photometer System Data Processing Flow Diagram 
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SECTION 4 


PROCESSING REQUIREMENTS OF THE BOUNDARY SENSORS 


This section discusses the derivation of data processing approaches suitable for an on-board processor, 
the partitioning of the processes between on-board and ground and the resulting requirements for the on- 
board processor and the ground system. 


4.1 ONBOARD PROCESSING REQUIREMENTS 

The OEDSF operates in real time. Accordingly, the processes it performs must be compatible with this 
mode of operation. A major effort of Task 2 was to convert the processing requirements of the boundary 
sensors into real-time processes. Figure 4-1 is one of four charts representing the processing require- 
ments of the IRS. Figure 4-2 is one of the nine charts which converts these requirements into a set of 
real-time processes for the IRS. The total set of these processes indicate the logical partitioning for 
processes to be performed on-board and for those to be performed on the ground. The set of criteria 
selected to effect this decision is summarized in Table 4-1 and discussed in the following paragraphs. 


1. Processing performed on-board by the OEDSF should satisfy all the users of the data . OEDSF 
processing stops where different users begin to process the data differently. 

Many experiments gather data which can 

be used in several ways. In most cases, Table 4-1. On-Board/Bround 

fundamental calibration and correction Partition Criteria 


processes and the extraction of basic in- 
formation is common to all uses. Addi- 
tional processing is peculiar to the specific 
use. For example, surface temperature 
information is ul : lized and processed 
differently when it is used for meteorology, 
crop yield estimation, or energy balance 
studies (Albedo). The OEDSF is an effec- 
tive device when it performs processes com- 
mon to all users since it eliminates the 
duplication of these processes by the in- 
dividual users, or expedites delivery of 
their data by avoiding the delay they would 
incur if these common processes were 
performed in a single ground facility fol- 
lowing the return of the shuttle. Further, 
the chief benefits derived from on-board 
processing (real-time availability of 
ancillary data, for example) tend to be 
realized in the primitive processes, which 
usually are also the common processes. 

2. All on-board processing will be on-line in 
real or near-real time. Data will not be 


, ON-BOARD PROCESSES SATISFY ALL USERS 
* ON-BOARD PROCESSING IN REAL TIME 
. NO LARGE QUANTITIES OF PRE-STORED DATA ON-BOARD 
. NO FREQUENT UPDATE OF ON-BOARD PRE-STORED DATA 
. NO GROUND REPEAT OF ON-BOARD PROCESSES 
. ON-BOARD PROCESSES WELL DEF INED AND STABLE 
, CLEAN INTERFACE TO GROUND PROCESS ING 
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Figure 4-1. Processing Requirements (Typical Example) 


tv •■ ■ 

ll - • 


r ^ 


■yt3 
■■ * 


r> 


Ft 

*: 


■J 
• } 




P-- 




tt'.nvi 


f/ 4 '- ':.svs 


Kv: 

*£ 


£3 g 


-9 L— •] 









4-3 












stored for long periods of time and processed in batches. This criterion is derived from two 
basic tenets of the OEDSF cost-effectiveness concept: It must exploit the features available on- 
board but not on the ground; it must not perform processes which simply convert ground equipment 
into flight equipment. 

The major feature of on-board processing is the real time availability of ancillary data which 
includes shuttle location and attitude, instrument characteristics such as pointing parameters and 
operation (housekeeping), and other calibration data such as sun angle, sun radiance, and the 
information provided by auxiliary sensors. This feature is exploited only when the real time 
aspects are utilized. Storing this data and performing batch processing duplicates the operation 
of present ground processing modes. Further, it requires storage facilities which tend to be 
large and difficult to qualify for space flight. 

3. Pro ce sses requiring large quantities of pre-stored data (i. e. , look-up) will be performed on the 
ground . The term "large” is a variable depending primarily on the memory requirements. The 
criterion derives from the obvious deleterious effecic of having to provide large memoiy capacities 
on-board. It is supported by the fact that in most cases, the processes requiring these pre- 
stored data tend to be in the more advanced categories rather than the basic processes which the 
OEDSF is ideally suited to perform. 

4. Processes requiring pre-stored data which must be periodically updated w ill be performed on 
t he ground; however, infrequent uplinks of updated data which enhances onboard processing is 
allowable. This criterion is primarily based on the premise that processes requiring regularly 
updated pre-stored data tend to be the more advanced and specialized processes which no longer 
benefit fx-om onboard features. It is recognized that there will be many exceptions to this premise 
so that, although it is a first order guideline, it is subject to re-examination where it eliminates 
primitive processes. The cost of providing an up-date feature must be weighted against the loss 
of the benefits of on-board processing. 

5. The location of the on-board/ground partitioning must not require any extensive on-board process 
to be repeated on the ground. There are frequent instances when the data must be reformatted 
following a series of processes. The data must also be reformatted if it is to undergo recording 
or transmission following any portion of this series, then again reformatted prior to and following 
undergoing the remainder of the series. Examples are domain transformation and resampling. In 
such instances the entire series should be performed on-board or on the ground. If the initial 
processes in the series strongly benefit from on-board processing, even though the remainder of 
the series does not then the entire series should be performed on-board. 

Trade-offs must be effected weighing the on-board processing advantages and disadvantages of the 
initial and subsequent processes versus performing the entire set on the ground. 

6. Processes performed on-board must be well defined and not subject to frequent and extensive 
changes. Experimental and user modeling processes will be performed on the ground^ The 
configuration and qualification of flight equipment is expensive. The benefits to be derived from 
on-board processing will be realized only if costs are kept within reasonable limits. Frequent 
changes and modifications requiring extensive rework of the OEDSF will rapidly erode the cost 
advantages inherent in its functions. 

User models are devices intended to measure the validity of a set of theories by correlating mea- 
sured facts against predictions derived from the theories. As such they are subject to changes 
and modifications as the measured data modifies the theoiy. 

The output of this study is a conceptual design for an onboard processor. Such a processor cannot 
be designed when the processes it is required to perform are not defined or are subject to frequent 
changes. 
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7. The characteristics of the data at the partitioning interface must be such as to enable efficient 
continuation of the processing or utilization. The basic benefit to bs derived from the OEDSF is 
an overall cost effective system. Data delivered to the ground in a state, configuration or format 
which, imposes additional complex or extensive processes to continue its further processing 
diminishes the system effectiveness. The data output from the OEDSF must be "clean" in the sense 
that it is compatible and easily interfaces with the next set of processes, and maintains a minimum 
profile in terms of format, ancillary information needs, and conciseness. 

These criteria are more correctly referred to as guidelines since each is subject to exceptions or modifica- 
tions for any given set of requirements. In certain cases, some of them are contradictory. For example, 
the use of frequently updated data may eliminate the repeating of extensive processes on the ground. Trade- 
offs between these guidelines may therefore be one of the first steps in partitioning candidate systems. 


A criterion whioh provides guidance as to allowable on-board processors size, power and memory require- 
ments is conspicuous by its absence. It became evident that any assignment of quantative values to these 
items would be unnecessarily restrictive on the on-board segment at this time. There are obviously limits 
for these parameters on the OEDSF as an entity; however, these will be a function of the sum of all the 
processes required by ail the serviced sensors and the apportionment of space and cost to the OEDSF which 
will, to a large extent, be determined by its value. These limitations will create trade-offs between the 
extent of on-board processings for given sensors and the number of sensors serviced, for example. Thus, 
in the process to establish the desirable OEDSF capabilities it is reasonable to exclude from on-board con- 
sideration only those processes whose physical needs are obviously excessive, suoh as a gigabit memoiy. 


The application of these criteria was combined with modifications of the processes to meet the criteria such 
that the on-board/ground partition tended to maximize the number of processes performed on-board. Table 
4-2 summarizes the impact of these criteria on the required processes. 


The rationale for each system is indicated below and correlated with the applicable criteria on Table 4-2. 


1. ATS - The onboard processing consists of all pre-processing of the data. This includes Calibration, 
Radiometric Correction and Geometric Correction. The Geometric Correction encompasses X and 
Y correction based on GNC data providing information on the shuttle attitude and altitude, and on 

an Earth Model providing information on earth curvature and rotation skew. Ground Control Point 
(GCP) Correlatfon is also performed onboard even though this process does not benefit from any 
inherent on-board processing advantage. The major reason for this decision is that the data must 
be resampled prior to recording or transmitting to the ground. If GCP correlation were performed 
on the ground, an additional resampling process would be required following this correction, A 
double resampling process introduces radiometric errors which reduce the radiometric accuracy 
below that desired for many applications. Information Extraction processing is performed on the 
ground because the optimum approach to this task is dependent on the user; i. e. , the process to 
extract wheat acreage is different from that to highlight geological features. 

2, IRS - The onboard processing consists of all processing required to derive the raw temperature 
profile and mixing ratio profile as a function of position. The process is carried this far on-board 
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31 Table 4-2. Impact of On-Board/Ground Criteria on Boundary Experiments Processing 


CRITERION 

E^'ER S ''> S , 

1 

2 

3 

4 

5 

6 

7 

ATS 

PROCESSING 
RESTRICTED TO 
CALIBRATION 
AlO PREPROCESSING 
(CAL 1BRATION. 

GEO * :tric AND 

RAO.JMETRIC 

CORRECTION) 

MODIFIED GCP 
CORRELATION 
TO PREDICTIVE 
APPROACH USING 
KALMAN FILTER 

N A 

ABILITY TO 
PERFORM GCP 
CORRELATION 
WITH 3 POINTS 
PER FRAME 
REDUCES REQ'MTS 
FOR UPDATE TO 
TOLERABLE 
QUANTITY 

PERFORM GCP 
CORRELATION 
ONBOARD TO 
AVOID A SECOND 
RESAMPLING 
PROCESS 

NO INFORMATION 
EXTRACTION 
PERFORMED 
ONBOARD 

ACHIEVED BY 
IMPLEMENTATION 
DATA XMTO IS 
GEOMETRICALLY 
AND RADIOMETRIC 
ALLY CORRECT. 

IRS 

OUTPUT OF OEOSF 
15 RAW TEMPERA- 
TURE PROFILES 

NEW TECHNIQUES 
DEVELOPED TO 
AVERAGE CAL 
VALUES BEFORE 
AND AFTER DATA 

TEMP. ANALYSIS 
REQUIRING 
PREVIOUS DAY’S 
TEMPERATURES 
PERFORMED ON 
GROUND 

MODIFICATION 
OF PROCESS 
ALLOW 5 ON- 
BOARD PRO- 
CESSING OF 
FUNCTION WITH- 
OUT GROUND 
UPDATE OF 
PREVIOUS DAY'S 
TEMPERATURE 

ONBOARD 

PROCESS 

OBVIATES 

NEED TO 

CONVERT 

RADIANCE 

TO TEMP. 

AND VICE 

VERSA IN 

SUBSEQUENT 

PROCESSING 

FINAL TEMP. 
ANALYSIS 
PERFORMED ON 
GROUND 

DATA XMTD IS 
TEMP. AS A 
FUNCTION OF LAT. 
AND LON. 

RAD SAT 

OUTPUT OF OEOSF 
ARE 0 o AND T, 
WHICH ARE BASIC 
VALUES 

EXTENSIVE 
UTILIZATION 
OF REAL 
TIMF ANCILLARY 
OAT A 

M' A 

N/A 

n/a 

UTILIZATION 
OF Oo AND T» 
FOR VARIOUS 
MODELS PER- 
FORMED ON 
GROUNO 

DATA XMTD iSOo 
AND T* AS A FUNC- 
TION OF LAT. AND 
LON. 

CIMAT5 

OUTPUT OF 
OEOSF IS 
SPECIE 

CONCENTRATION 

EXTENSIVE 
UTILIZATION 
OF GNC DATA 
IN REAL TIME 

STORED INTER- 
FEROGRAMS 
ARE DEEMED 
SMALL AND 
VITA^ TO 
BENEFICIAL 
ONBOARD 
PROCESSING 

N/A 

complete 

PROCESSING 
ONBOARD TO 
OBTAIN 
SPECIE CON- 
CENTRATION 
ELIMINATES 
FURTHER 
GROUND PRO- 
CESSING 

H-'A 

DATA XMTO 
IS SPECIE 
CONCENTRATION 
AS A FUNCTION 
OF LAT., LON., 
AND ALTITUDE 
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because the position data required in these computations is readily available in real time. The 
temperature analysis is performed on the ground because this process requires a complete refer- 
ence of the previous day's temperatures for each subgrid point at each altitude level. The output of 
this process is a set of plots (one for each altitude). The process gains nothing from being per- 
formed on-board and is more efficiently performed with large general purpose computers. 

3. RADSCAT - The on-board processing consists of the computation of the backscatter cross-se'ction 

( a D ) and the antenna temperature (Ta) as a function of position (latitude and longitude). Subsequent 
processing is performed on the ground for a couple of reasons. First, there are several para- 
meters requiring differing processes which can he derived from these two values; second, the 
procedures for determining these parameters are presently not well defined. 

4, CIMATS - The entire processing of the CIMATS data yielding specie concentration as a function 
of altitude and location is performed on-board. Any subsequent processing involves user models, 

4.2 QEDSF REQUIREMENTS 

This section establishes the data processing requirements of the OEDSF. 


The requirements are derived from the on-board segment of the functional flow diagrams in Section 3. 
These houndary sensors, by definition, establish both the spectrum extremes for signal characteristics and 
the extremes of the processing complexity. 


The OEDSF must handle many experiments from several disciplines, thus the processing requirements 
established by the boundary sensors must be generalized, and ho processing capability of the OEDSF 
derived from these requirements must be implemented with sufi'c. ent flexibility to perform more than these 
processes. 

The approach taken to determining OEDSF requirements which satis' this objective is described below. 

The closed functions depicted in the functional flow diagrams are not merally the process requirement. 
These closed functions are the mathematical relationship which the Ol 'SF must model. Consequently, 
each relationship must be described as a set of functions interrelated a i generally termed an algorithm. 
Ramifications result based on the level of decomposition of the closed fu ^tion. The depth of the decom- 
position is a variable which must be selected to optimize the combination € the conflicting objectives of 
general purpose and low cost. If the decomposition is too shallow, a spec U purpose, sensor unique 
function, results. If the decomposition is too deep, a general purpose mar. ina results that is too cumber- 
some from an implementation and user standpoint. 

The detailed work performed in this task is contained in Appendix A of the T sk 2 report. 


The required processing functions tabulated on the flow diagrams were extra ;tad and converted to an im- 
plementation process; i, e. , the actual process which will implement the required process. Algorithms 
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were then developed io perform this process. The steps of the algorithms were then grouped as the set of 
functions required, 

Requirements which create only functions already developed are not considered again. The vast majority of 
functions developed in Appendix A of the Task 2 report were provided by the early processes of the CIMATS 
and the IRS, The only new functions supplied by the RADSCAT, for example, was Matrix Multiplication. 
Processes required in handling housekeeping and command data were also considered and found to be well 
within the envelope defined by the data processes. 

The required functions were generalized and grouped into process categories. Table 4-3 tabulates the 18 
functions derived from Appendix A grouped into the four process categories. 

Table 4-4 summarizes the characteristics of the boundary sensors. 

Table 4-3. OEDSF Functions Required 
1. TEIGNOMETRIC FUNCTIONS 


a. 

Sine 

f. 

Cosecant 

b. 

Cosine 


Inverse Sine 

c. 

Tangent 

h. 

Inverse Cosine 

d. 

Cotangent 

i. 

Inverse Tangent 

e. 

Secant 




2 . exponential junctions 

a. Exponential 

b. Natural Logarithm 

3. ALGEBRAIC FUNCTIONS 

a. Algebraic addition with accumulation capability 

b. Signed multiplication with reciprocal input capability 


CONTROL FUNCTIONS 


a. Multiplexing 

d, Counting 

b. Demultiplexing 

e. Delay 

c. Storage and Retrieval 



Table 4-4. I oundary Sensor Characteristics 



PROCESSES/CHANNEL 

FREQUENCY IN BPS 


WORD 

SIZE 

DATA 

BASE 

(BITS) 

SENSOR 

ARITH 

TRIG 

LOG/EXP 

TOTAL 

CHANNEL 

CHANNELS 

ATS 

82 

15 


120 X 10 6 

1 X 106 

120 

8 BITS 

1Q0K 

RAD/ SCAT 

213 

67 

0 

15X103 

15X103 

1 

10 BITS 

10K 

IRS 

131 

0 

4 

3.3X103 

1.99X102 

17 

18 BITS 

25QK 

Cl MATS 

31 

19 

0 

2. 904 X 103 

2.904X 102 

10 

. 

12 BITS 

170K 


4.3 OEDSF GROUND SYSTEM REQUIREMENTS 

This section examines the requirements imposed on the ground segment of the four boundary experiments 
data systems as a result of the partitioning. The intent of this examination is to enabie a gross evaluation 
of the effectiveness of the entire system to ensure that processes performed on-board and the location 
of the on-board/ground partition do not reduce the advantages of on-board processing by creating new and 
extensive processing requirements on the ground. The partitioning location is summarized in Figure 4-3, 

ATS - The data provides information useful to many disciplines such as agriculture, forestry, geology, 
urban planning, and hydrology. The information required is extracted from data provided in several 
spectra, over a period of time, and correlated with other information obtained from exogeneous sources. 
Figure 4-4 depicts a generic data processing system indicating the onboard/ground partition for the ATS 
system. 

The ATS data input into this system undergoes several processes which render it useful for the particular 
application. These are, in general, a function of the specific application; however, alL applic ations share 
a common need which define the basic processing of the data. These are; calibration, radiometric correc- 
tion, and geometric correction. These processes will be performed on-board; all subsequent processes will 
be performed on the ground. The data supplied to the ground is radiometric ally and geometrically corrected 
digital data. The processes which may then be performed on the ground are as various as the uses of the 
data. 

Typically they consist of information extraction which may be performed by thematic techniques, typified 
by the Image 100, an interactive thematic extraction processor. (The reader is referenced to the OEDSF 
Task I report. Pages A~41 to A-49). This is followed by user modeling which combines this information 
with information obtained from other sources to create a final output product. For example, ATS data 
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Figure 4-3. On-Board/Ground Partitions 
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Figure 4-4. ATS Data System 

providing information on crop acreage and health may be combined with meteorological information pro- 
viding temperature and soil moisture ,o determine crop yield. 

The specific ground requirements which may be specified relate to the input interface. The output of the 
OEDSF will usually be recorded on a High Density Digital Tape (HDDT) on the ground. The ground facility 
must be capable of converting this tape to a Computer Compatible Tape (CCT) or directly to imageiy. These 
requirements would exist without the OEDSF, since raw ATS data would be recorded on an HDDT. The 
ground segment requirements of the system are thus reduced to the extractive and user model require- 
ments by the elimination of the need to prepiocess the data. 

IRS - The IRS provides atmospheric temperature profiles and earth surface temperature as a function 
of location. This information may then be used in user models to support various disciplines, in particular, 
meteorology. The basic process to extract the information from the sensor data, and the location of the 
on-board/ ground partition are Indicated in Figure 4-5. 

The data delivered to the ground are the raw temperature profiles and mixing ratio profiles as a function of 
location. 

The ground system must perform the surface temperature analysis. This process is identical to that per- 
formed at present on the HIRS data, and the same program developed for that phase of the processing may 
be used. One step has been added as a result of the method used to implement the on-board processing. 

If an unsufficiently clear field of view exists in a sub-grid, a flag is set, and a bilateral estimate temperature 
value based on the average of the four nearest qualifying neighbors is used in further processes. The 
present approach {all ground) is to use the previous day's temperature for this sub-grid. The use of the 
estimated temperature instead of the previoue day's temperature in the data processing produces at worst 
a second order error; the estimated temperature can be replaced with the previous day's temperature 






ONBOARD -«j™ — — ^-GROUND 

Figure 4-5 . IRS Data System 


during the analysis operation by a simple modification of the existing program. Presently the analysis 
1 program performs various checks on each sub-grid temperature and replaces it with the previous day'B 
temperature if it falls any of these. The modification consists solely of adding a flag set check to the 
! other checks, and considering a set flag as a check failure. 

All other ground processing, including user models, are unaffected and retain their present requirements. 

RADSCAT - The RADSCAT is an instrument consisting of a radiometer and a scatterometer which produce 
data from which basic parameters of their target may he derived. These basic parameters are, the baok- 
scatter crossection (o 0 ), and the target temperature (T*) The computation of the target temperature is based 
on the radiometer antenna temperature (Ta) and uses several other data (which may include (o Q ) obtained 
from exogeneous sources. The complexity of this process, depends on the accuracy of T desired. For 
several applications Ta is sufficient; thus the computation of T t is a user model function. These two 
parameters may be used singly or in conjunction with each other (or with other data) to produce information 
on several characteristics of the target. Examples of information derived from these parameters are: 

Sea wave height, wind velocity and direction, soil moisture, crop stress, geological surface features, 
water salinity and temperature, and forestry management parameters. 

The generic data processing diagram for the RADSCAT is shown in Figure 4-6. 

The present RADSCAT ground system consists of two basic entities. The preprocessing and processing are 
performed at a central facility. The output of this facility are a o and Ta as a function of position. This data 
is distributed to various users most of whom are presently In the experimental phase; i. e. , developing 
and evaluating models which produce the final information in their own facility. 

The OEDSF performs the preprocessing and processing functions and outputs the identical product as that 
supplied by the present facility; hence, there is no impact on the user models and subsequent processing 
of the RADSCAT data by the OEDSF. 

CIMATS - The CiMATS produces data which enables the determination of the column density of a number 
(approximately 9) of gas constituents of the atmosphere as a function of altitude and location. 
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Figure 4-6. HADSCAT Data System 

The initial utilization of this information is the study of pollution. Corroborative measurements made from 
the ground are used in this study. There will undoubtedly be many other uses of the CIMATS information 
related to the concentration of various gases singly or in group. These are all user model functions. 


The generic processing flow of the CIMATS data is shown in Figure 4-7, 


The CIMATS pre-processing function is unique in that it is really the early phases of information extraction 
rather than the more classical calibration and correction functions associated with this term. 


The entire information extraction process is performed on-board. The input to the ground system are the 
specie concentrations as a function of altitude and location. These are submitted to the user models which 
are undefined at this time. The format of the supplied data will be High Density Digital Tapes. 



Figure 4-7. CIMATS Data System 






SECTION 5 

COMPOSITE SENSORS 


The boundary seas or a discussed in Section 3 exhibit upper limits of processing complexities and/or data 
rates. The OEDSF must provide data processing support to payloads made up of instruments which, in 
general, fall within the boundaries of these "tall poles". In order to derive realistic requirements for the 
OEDSF in supporting typical payloads a '’typical" sensor was developed. It was assumed that an average 
payload will contain 20 of these "typical" sensors. Since this sensor was derived from a large number of 
specific sensors, we have named it the "Composite" sensor. 

The derivation of the requirements of the composite sensor was accomplished as follows: 36 instruments 
which are candidates for near-term shuttle flights were considered with respect to both their data rates and 
processing requirements complexity. The data rate of the composite sensor A is the average of the rates 
of all 36 instruments. The processing complexity was determined by: (a) assigning each of the 36 sensors 
into a "similar to" group determined by the four boundary sensors; (b) averaging the processing require- 
ments based on the number of sensors assigned to each category and the specific requirements of these 
categories, i.e., the boun dar y sensors. The result of this analysis is shown in Figure 5-1. 



Figure 5.1. Composite Sensor Derivation 
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It is evident that a vary small number of very high frequency instruments such as the Advanced Technology 
Scanner, and the Synthetic Aperture Radar distort the average rate significantly from average payloads 
where these instruments are not flown. Accordingly, a composite sensor B was derived which excludes 
these high data rate sensors and is more representative of typical payloads. Analyses discussed in Section 
9 indicate that these very high rate sensors require most of the capability of a full OEDSF array and should, 
therefore, be treated separately from the rest of the payload. Table 5-1 summarizes the characteristics 
of Composite Sensors A and B. 

These processing requirements combined with the characteristics of the boundary sensors determine the 
capabilities required from the OEDSF. These are summarized in Table 5-2 where an operation is defined 
as a function that is executed based on a single instruction. Typical operations are: 

« f (x) = ax + b 
o f (x) = cosine x 
» f (x) - A exp(x) 

® f (x) = X + Y 


Table 5-1. Composite Sensor Characteristics 


■■ 1 11 ' — ' 

Parameter 

Composite Sensor A 

Composite Sensor B 

Frequency 

3.0 Mega i- is /Second 

190 Kilo Bits/Seoond 

Arithmetic Processes (Per Word) 

1250 

1160 

Trigonometric Processes (Per Word) 

288 

250 

Exponential Processes (Per Word) 

36 

40 

Number of Channels 

18 

10 

Word Size (Bits) 

12 

12 

Buffer Size Required (Bits) 

84K 

93IC 

Memory Size - Required (Bits) 

118K 

131K 
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Table 5-2. Machine Requirements 


PARAMETER 

REQUIREMENT 

» BANDWIDTH 

D.C. TO 120 MEGA BITS/SECOND 

• OPERATIONS PER SECOND 


- COMPOSITE SENSOR A 

2. 2 X 10 7 OPERATIONS/SEC 

- COMPOSITE SENSOR B 

2.4X 10*> OPERATIONSTSEC 

• PROCESS DISTRIBUTION 


- ARITHMETIC 

80% OF CAPABILITY 

- TRIGONOMETRIC 

18% OF CAPABILITY 

- EXPONENTIAL 

2% OF CAPABILITY 

• STORAGE REQUIREMENT 


- BUFFER/SENSOR A 

84 KILO BITS 

- DATA BASE/SENSOR A 

118 KILO BITS 

- BUFFER/SENSOR B 

93 KILO BITS 

- DATA BASE/SENSOR B 

131 KILO BITS 

• PORT REQUIREMENT 


- INPUT 

18-12 BIT PORTS (MINIMUM) 

- OUTPUT 

18-12 BIT PORTS (MINIMUM) 



SECTION 6 

AECHITECTURE OF THE OEDSF 


By definition, architecture is the art or science that pertains to the method or style in which some physical 
structure is built. In electronic signal processing, an architecture is more explicitly defined as the method 
of establishing the inter-signal relationship with respect to the processes or transfer functions comprising 
the system. At the system level, architecture defines the processing philosophy and dimensional distribu- 
tion. Processing structures are further characterized as functions of time. 

The various architectures considered for the OEDSF are described in detail in the OEDSF Task 2 Beport 
dated December 1975, The following is a summary of this report. The applicable architectures were 
reduced to the following: 

For the Central Processing Unit: 

« Augmented small computer 

• Pipeline 
® Serial 

• Matrix (or array) 

And for the System Level: 

e Centralized 

• Distributed 
t* Structured 

The characteristics of these architectures are summarized in Figures 6-1 through 6-7 and Tables 6-1 
through 6-4. 

These characteristics were matched to the requirements of the OEDSF shown in Table 6-5. 



Figure 6-1. Augmented Computer Architecture 


Table 6-1. Augmented Small Computer 


Advantages 

1 . Any Algorithm can be Implemented Regardless 
of the Complexity 

2. System Modifications are Facilitated and 
Dynamic in Nature 

3. System Modifications are Reversible and not 
Time Consuming 

4. System Structures* Flows, and Interactions 
are not Rigidly Defined 

5. Uncertainties may be Incorporated, Modeled, 
and Altered without Ramifications on the 
System 

6. Documentation is User Oriented Rather than 
Designer Oriented 

7. Interfacing is Standardized and Documented 

S. Powerful Decision Making and Sequencing 
Capability 


Disadvantages 

1. Operational Speed is Limited By Basic 
Machine Time 

2. Applicability is Determined by the Data 
Rate and Format in Conjunction with the 
Required Algorithms 

3. Internal Processing is serial 

4. Software is Dedicated to a Specific 
System 

5. Algorithm Complexity Establishes 
Memory ar 1 Power Requirements 

6. Machine Power is Determined by the 
Machine Architecture and the instruc- 
tion Set 


\ 
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Figure 6-2. Pipeline Architecture 


Table 6-2. Pipeline Architecture 


Advantages Disadvantages 


1. High Speed Processing Directly Proportional 
to the Number of Stages 

2. Speed of Operation is Independent of the Proc- 
esses Used 


3. Control of the Pipeline is Simple and Indepen- 
dent of the Complexity of the Processing 

4. The Architecture is Modular at Every Proc- 
essing Level 

5. Adaptive to Mathematical and Information 
Processing 

6. Possesses Unlimited Growth Potential 


1. Requires Efficient Algorithms Easily 
Decomposed to Simple Sequences 

2. Normally Complex in Design and Realized 
in Special Purpose Hardware, Firmware, 
and Software 

3. Inefficient on Small Arrays of Data 

4. The Structure must be Either Output 
Coupled or Input Coupled 
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Figure 6-3. 

Serial Architecture 

Table 6-3. 

Serial Architecture 

Advantages 


Disadvantages 

1 . Limited Hardware Requirement 

1. 

Low Operational 

2. High System Level Efficiency 

2. 

Inefficient at the Processing Level 

3. Capable of Complex Algorithms 

3. 

Limited Growth Potential 

4. Economical 

4. 

Time -Shared Bus Orientation 

5. Electronic Modification of Signal Flow 
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Figure 6-4. Array Architecture 


Table 6-4. Array Architecture 

Advantages Disadvantages 

1. Capable of Complex Algorithms 1. Effective only with Large Arrays of Data 

2. High Operational Frequency on Large Arrays 2. Complex Fabrication 

3. Simultaneous Word Processing of Large 3. Low Gate Efficiency 

Blocks of Data 

4. Electronic Signal Flow Modification 

5. Elimination of Feedback Loops 

6. Control and Programming Simplicity 
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Figure 6-5. Centralized Architecture 
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Figure 6-6. Distributed Architecture 
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Figure 6-7. Structured Architecture 
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6.1 OEDSF ARCHITECTURE DRIVERS 


Table 6-5. OEDSF Architecture Drivers 

• Multiple Experiments 

• High Data Rates 

• Real Time Processing 

• Flexible Configurations 

• Physical Characteristics 

• User Orientation 

• Spaceflight Qualification 

• Growth Potential 

1. Multiple Experiment s. The shuttle will carry payloads typified by several missions in different 
disciplines each of which will use multiple Instruments. The OEDSF must then be capable of 
simultaneously processing the data of many instruments which are uncorrelated with respect 
to processes, data rates, or format. 

2. High Data Rates. The OEDSF is designed to accommodate the high data rate instruments which 
are candidates for shuttle flights. These include the Advanced Technology Scanner and Synthetic 
Aperture Radar which output data in excess of 100 megabits per second. 

3. Real Time Processing. The onboard/ground trade-offs discussed in section 4 conclude that on- 
board processing must be performed in real time if it is to be effective. The OEDSF must thus 
be capable of accc mmodating the required processes and data rates output by the sensors in 
real time. 

4. Flexible Configurations. The shuttle flies repeatedly with different missions and sets oi instru- 
ments. The OEDSF must rapidly and inexpensively be reconfigured to accommodate each flight 
complement. 

5. Physical Characteristics. The shuttle is large but its accommodations have already been allocated 
to the many candidate experiments. The OEDSF must present a low profile in terms of size, 
weight and power requirements to present an attractive alternative to ground processing. 

6. User Orientation. The OEDSF is conceded to primarily benefit the user in terms of timeliness 
of data availability, data quality, and cost. These imply a system which must readily interface 
with the user in terms of both its inputs and its outputs. Specifically, the programming of the 
OEDSF must be simple, inexpensive, and oriented towards the user's normal methods of operation. 

7. . Space Flight Qualification. The OEDSF is a central facility in a manned spaceflight environment. 
This circumstance implies reliability and safety features which must be inherent in ihe design of 
the facility and in its component parts . 

8. Growth Potential . The OEDSF must be able to accommodate future generations of instruments awl 
to assimilate advances in the state of art pertaining to its own structure. For example, the design 
should enable an LSI implementation when this technology becomes applicable to the OEDSF design. 
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Table 6-6 indicates the trade-off evaluation given to each of the parameters of importance to the OED3F. 

High speed requirements indicate a pipeline approach; the need to service multiple sensors expand this to 
multiple pipelines; and the changing sensors configuration dictate that this set of pipeline processors be 
reconfigurable. a tie solution to the requirements thus rapidly converge on an architecture which is a set 
of programmable pipelines. 

This architecture can be constructed in several ways as indicated in Figure 6-8 where each block performs 
a different function; i.e., El is a function different from E2 which is different from E3. The configuration 
selected is that shown in Figure 6-9. The blocks labeled A perform Algebraic functions, those labeled T 
perform Trigonometric functions, those labeled E perform exponential functions. The specific functions 
are described in Section 7. The population density and the location of each type function was determined 
by the analyses of the processing requirements defined in Sections 4 and 5. 


The concept of this architecture is best understood by application to an example. 


A sub-routine required for the sub-limb longitude and latitude calculations is used. The calculation 
requires the solution to the equation 


aft) = COS" 1 1 1 + COT ^ COT X 2 COS ^ 


The variables \j, x 3 , <t>2> and $1 have been previously defined. This process is performed in five machine 


cycles as follows: 



1 . 


Machine Cycle One. The array configuration during 
the first machine cycle is shown in Figure A. Three 
processing elements are required. Processing Element 
(PEji) is an arithmetic element which computes the 
difference between the sub-satellite longitude (4>j) and 
the solar longitude (0 2 ). Processing Elements (PE 12 and 
PE 2 i) are trigonometric processing elements which com- 
pute the cotangent of the solar latitude and sub-satellite 
latitude respectively. Each machine cycle is sub- 
divided into control states so that during the last state 
the computed variables are placed on the array bus. 
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Table 6-6. Comparison of Processing Architectures 


EVALUATION CRITERIA 

SMALL COMPUTER 

SERIAL 

PIPELINE 

MULTIPLE SENSORS I/O CAPABILITY 

POOR 

POOR 

POOR 

OPERATIONAL SPEED 

POOR 

FAIR 

EXCELLENT 

FLEXIBILITY OF PROCESSING 

EXCELLENT 

GOOD 

POOR 

GATE UTILIZATION EFFICIENCY 

POOR 

POOR 

EXCELLENT 

REAL TIME CAPABILITY 

POOR 

FAIR 

EXCELLENT 

IMPLEMENTATION Or COMPLEX 
ALGORITHMS 

EXCELLENT 

GOOD 

GOOD 

USER ORIENTATION 

EXCELLENT 

FAIR 

FAIR 

ADAPTABILITY TO FLIGHT 

GOOD 

GOOD 

GOOD 


ENVIRONMENT 

GOOD FAIR EXCELLENT 


ARRAY 

EXCELLENT 

EXCELLENT 

EXCELLENT 

GOOD 

EXCELLENT 

GOOD 

EXCELLENT 

GOOD 

EXCELLENT 


GROWTH POTENTIAL 







































The program for the first machine cycle is 


M0 l - PE 11 <[ B u] - [ C ld » pe 12 (cot [°ia] » ! PE 21 (C0T E B 2l3 > 

where B , and are the input and output ports as shown in Figure 6-16. 


2. Machine Cycle Two. The output state of machine 

cycle one reconfigures the array for the next machine 
cycle as shown in Figure B. 


The seaond machine cycle during the first sensor 
data period requires two processing elements to 
execute 

M0 2 = PE 21 (COS [PE n ] >, 

PE 22 < [ PE 2l] X [ PE 1 2 ] > 
forming the partial solutions 

* [ PE 2X] ‘ C0S <«2 - *1> 

® JPEggJ = COT Mo COT X 2 



n □ □ □ □ 

□ □ □ □ □ 

□ □ □ □ □ 

MACBIHE CYCLE TWO 

Figure B. 
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Processing Elements PEji and PE 12 are free for other assignments during this cycle. The last 
state of the cycle reconfigures the array. 

3. Machine Cycle Three. The third machine cycle, shown 
in Figure C, requires a single processing element, 
i.e., PE32 to execute the instruction 


MC 3 ‘ PE 32 < [ PE 2l] X [ PE W] > 


generating 

» [ pe 32 ]= cot h C0T H cos <* 2 " 0 x } 

4. Machine Cycle Four (Figure D). This machine 
cycle requires a single processing element 
PE42 to compute 

® [PE 42 J = 1 + COT A 1 COT \ 2 COS (0 g - 4^) 
based on the instruction 

“C 4 = EE 42 ( [pe 32 ] h- 1) 

The unity offset is fetched internally from a 
scratch pad or a hardwired function during the 
execution of the operation. 


5. Machine Cycle Five (Figure E). This cycle is the 
final cycle required to compute the dummy variable 
a(t). Processing Element PE^g is a trigono- 
metric processing element required to compute 


Kj 


= COS' 


+ COT X COT X COS(0- 
16 0 


- 0j) 


based on the instruction 


MC = 

D 


>®„] <C0S ' 1 [ PE 4 2 ] 


This sub-routine required five machine cycles to operate on 
the first data word. It is repeated every 58 words. The 
process required 1.25 microseconds and was executed using 
double precision. 


A full-blown example of the er'.ire processing of a sensor is 
given below. The sensor is the Correlation Interferometer 
for the Measurement of Atmospheric Trace Species (CIMATS). 


□ □ □ □ □ 

□ □ □ □ □ 

do □ □ □ 

□ □ □ □ □ 

□ □ □ n □ 

MACHINE CYCLE THREE 

Figure C. 


□ □ □ □ □ 

□ □ □ □ □ 

□ □ □ □ □ 

□ □ □ □ □ 

□ □ □ □ □ 

MACHINE CYCLE POUR 

Figure D. 

□ □ □ □ □ 

□ □ □ □ □ 

□ □ □ □ □ 

□ □ □ □ □ 

□ □ □ □ □ 

MACHINE CYCLE FIVE 


Figure E 
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CIMATS is an atmospheric sensor that is utilized in determining gaseous pollutant concentrates. The pri- 
mary system driver for the sensor is the correlation process required for an interferogram. The sensor 
is a relatively low frequency instrument that generates four output variables: 

e Thermal column density 
a Non- Thermal column density 

* Thermal spec concentrations 
e Non- Thermal specie concentration 

utilizing the process flow chart shown in Figure 6-10, This process flow chart was translated into a generic 
machine flow for real time data processing during Task n. The generic machine processing is shown in 
Figure 6-11. The real time relationships for the sensor provide the basis for programming the OEDSF. 

The generation of the four output variables based on the raw sensor data results in an approximate 60 to 1 
data reduction. The transformation places the OEDSF in an information processing role. 


The initial requirement is to investigate the processes to isolate loops and shared parameters. (At the 
multi-sensor level, many functions are also shared between sensors so that a single computation is re- 
quired) . 


The process flow chart for the CIMATS sensor on a programmable machine is shown in Figure 6-12. The 
flow is a machine flow and not a software flow chart. The primary purpose of this diagram is to minimise 
the sequential iterations and allocate the machine capacity. The sensor requires three major sequences 
and two loops to generate the required output parameters. The conversion from each flow to the machine 
flow is important to determine: 

® Program size 
0 Machine loading 

® Machine efficiency 

* Hardware allocation 


The OEDSF, like any machine, is finite and characterized by finite parameters. The sensor must be mated 
to the machine in conjunction with other sensors and a resource allocation assessed . The major considera- 
tions on any machine are; 

* Input/output port availability 
9 Data transfer rate 
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Figure 6-10. CIMATS Data Processing 
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Figure 11a. CIMATS Sub Limb Measurement 
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Figure 6-llb. CIMATS Non-Therinal 
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Figure 6-lle. CIMATS Thermal Bauds 
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Figure 6-12. CIMATS Flow Chart for Array Processor 


The advantage of minimal input/output port availability and the disadvantage of high throughput for batch 
processing modes are direct inverses for real time multi-task modes. 


In addition, the I/O capability for the basic OEDSF is dependent on the matrix size. The present OEDSF is 
characterized by 28 input and 28 output ports without external multiplexing and demultiplexing. The inter- 
nal cycle time for the array is designed that the cycle (array period) is always small in comparison to 
the sensor data period. 


6.2 PROGRAMMING TECH 'IQUE 

The OEDSF is an advance ' a nal processor that requires a language that enables an operator to instruct the 
machine. The language is a numerical analysis oriented structure that was defined conceptually for the 
machine. The programming is presented in the following manner. 


• Parameter definition 

• Symbol table generation 

• Syntax development 
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e Sensor program 


® Sub -routine discussion 


The initial step in programming any machine is to assign a machine word for each primary and secondary 
data variable to be processed. This parameter definition shown in Figure 6-13 allows communication be- 
tween the programmer and the machine. Each input variable 

and output variable for the OEDSF is assigned a mnemonic. I solar latitude 11 '™ 05 

The parameter definition establishes the input/output port re- *1 ° sub-satellite longitude 

<b 2 = SOLAR LONGITUDE 

quirements for externally generated variables. The external A ° satellite altitude 

R - EARTH RADIUS 

port configuration for the CIMATS is shown in Figure 6-14. x K » sub-limb latitude 


Each primary variable is assigned a port as shown in Figure 


The input/output ports are defined along the peripheral proces- 
sing elements as shown in Figure 6-16. Input ports are 
designated as alphabetics A through D and output ports are 
designated as alphabetics E through H- The subscript 
designates in which processing element the port is located. 
The location of the processing element within the array 
determines the number of input/output ports externally 
available. 

In addition to assigning external variables to ports, the 
assembly program for the machine assigns an input port to 
each internally generated parameter that must be re- 
entered in the array. The port assignment table shown in 
Figure 6-15 was manually generated for the CIMATS 
sensor, The CIMATS sensor requires : 


X-j = SUB-SATELLITE ALTITUDE 

\ 2 ■= SOLAR LATITUDE 

= SUB-SATELUTE LONGITUDE 
$ 2 = SOLAR LONGITUDE 

A *> SATELLITE ALTITUDE 

R - EARTH RADIUS 

X x «■ SUB-LIMB LATITUDE 
» SUB-LIMB LONGITUDE 
CDjg T = NON-TKEHMAL COLUMN DENSITY 
CD t “THERMAL COLUMN DENSITY 
C NT = MON-THERMAL SPECIE CONCENTRATION 
Cy = THERMAL SPECIE CONCENTRATION 

l£ T = NON-THERMAL LIMB MEASUREMENT 
l|Jj T = NON-THERMAL NADIR MEASUREMENT 
l£ - THERMAL LIMB MEASUREMENT 

ij = THERMAL NADIR MEASUREMENT 
GOF » GOODNESS nF FIT 


Figure 6-13. Parameter Definition 


INPUT PORTS - 9 OUT OF 28 
OUTPUT PORTS - 7 OUT OF 28 


L .NT. 
t N 


14 out of 28 input ports 


« 8 out of 28 output ports 


Figure 6-14. CIMATS Prime Port 
Utilization 





This port utilization although initially high only requires 


» 9 out of 28 input ports 

® 7 out of 28 output ports 


for sensor unique processes. The remaining parameters are internally generated and/or sensor shared. 


A syntax is required to allow a programmer to enter symbolic 
representations of machine instructions- The preliminary 
syntax shown in Figure 6-17 was developed for the manual pro- 
gramming aspects. The syntax was formulated on the numer- 
ical analysis machine orientation similar to Fortran being 
orientated to mathematical expressions. The subscript WW 
denotes the matrix location of the destination processing 
element. This FE is the location where the desired operation 
will be performed. The subscripts XX, YY, ZZ denote the 
source processing elements for the control variables X,Y, 
and Z. Each variable may be selected from one of four sur- 
rounding processing elements. An input port is treated as 
a surrounding processing element. The operation code 
determines which function will be executed in the element. 

The actual syntax required for an autonomous assembly has 
not been defined in this study. 


X 1 ~ B 2 1 

■r- 

b 31 

* 2 = C 12 

.NT 

'l " 

A 31 

0-j = ^TJ 

.T 


02 = B 11 


= d 35 

> 

ii 

> 

tap* 

l T 

N 

= D 15 

X x =h 25 

e S2 

= a 21 

= E 54 

0 

= b 12 

CD NT = F 53 

H 25 

= d 12 

CDj= Frj-j 

F 52 

= B 14 

C NT =F 55 

a 51 

= E 5 1 

C T =F 54 

E 55 

“ D 55 


GOF 

= H 45 


Figure 6-15. Port Assignment 


The program for the CIMATS sensor is shown in Figure 6-18. The 
program format consists of five major portions: 

9 Array period 
a Sensor period 
* Prime sensor data program 
a Ancillary sensor data program 
a Comments 
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Figure 6-16. Processing Element 
Port Designation 
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PE WW 

[ PExx 

OP CODE 

• 

pe yv 
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DESTINATION j 

j ARGUMENT 

j OPERATION | [ 

ARGUMENT 

1 




^ - 



T 

, ■ 



Figure 6-17. Program Format 


Column one is the sensor data period as measured from a reference. This reference is arbitrary and 
establishes the first sensor word in the process. Typical reference may be: 

® Synchronization 

• Another machine cycle 

• Beal time clock 

Column two indicates the array machine cycles available during one sensor data word. The relationship be- 
tween the sensor data period and the array period is the basic principle of the OEDSF. This relationship 
expressed as 

T sensor 

T array 

must always exist. Consequently, many array machine cycles are available to process a single sensor 
data word which allows for each processing element to be timeshared. Column three is the program for 
the primary sensor while the fourth column is the program for the secondary sensor processes. Secondary 
processes are those required for the processing of prime data but not directly manipulating the prime 
variable, e.g. , sub-limb longitude and latitude calculations. The fifth column is a remarks section re- 
served for the programmer. 
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The overall CIMATS impact on the OEDSF with a 5 x 5 CPU and 260 nanosecond cycle is shown in Table 
6-7. The insignificant CIMATS loading oa a single OEDSF shows the powerful capability of the machine 
and the multi “sens or capability. The OEDSF, In addition, requires only 104 instructions compared to 
1024 instructions required in a general purpose computer. 

Table 6-7. CIMATS Processing Loading of the OEDSF 


Machine Cycles per Sensor Period 1, 652 

Machine Cycles Available per Process 95, 816 

Machine Cycles -Required per Process 250 

Array Cycle Utilization 0.26% 

Machine Operations Available per Process 2. 4 x 10 s 

Machine Operations Utilized per Process 872 

Machine Operation Utilization 0. 03% 

Program Length (Number of Instructions) 104 

Program Memory Size in Bits 2, 496 
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PE^fCPE^-*- 0); Pi: 5 j{[P£ !3 ]*-0); PL : .£r,(CPe 5 ^*-Oj;PE*-!(CP^ ! :-o);PE, l (:SP JI 7xCA, 1 ] 1 -PE 15 ([3FlJ>(( 
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Figure 6-18. CIFATS Data Processing Program 
for 5x6 Array Prcc^sor 
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SECTION 7 
DESIGN CONCEPTS 


This section discusses the approaches to the design of the OEDSF given the array architecture described 
in Section 6. These consider the requirements imposed on each segment of the processor, the alternate 
viable approaches, and their characteristics applicable to the requirements, the criteria applied to the 
trade-offs performed between these approaches, and the selected approach for each of the segments, 

7,1 OVERVIEW 

The OEDSF is specifically designed to cost-effectively process onboard Shuttle data of multiple instruments 
with data rates ranging from a few bits per second to over 100 megabits per second. 

The OEDSF is a data processing oriented, distributed machine characterized by sets of programmable 
pipeline processors. The distributed architecture derives from the allocation of discrete elements to 
the performance of dedicated functions. It is a central facility in that it is shared by many instruments. 

The advantages of a central faoilily in the role of the OEDSF are: 

1. Sharing of common processes such as computation of latitude and longitude. 

2. Interactive processes whereby the data output of an instrument is used in the processing of 
another. 

3. Repeated utilization on many Shuttle flights by simple reconfiguration of the control program. 

The OEDSF is modular by addition of array structures as shown in Figure 7-1. 

Eaoh array is a programmable processor with the six-point architecture shown In Figure 7-2. The major 
elements of the array are: 

• Input Structure 
« Output Structure 

e Central Processing Unit 

a Data Base Memory Structure 

e Program Memory Structure 

• Controller 
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THE ARRAY CONSTITUTES SETS OF PIPELINE 
PROCESSORS CONFIGURED BY PROGRAM 
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E - EXPONENTIAL AND LOGARITHMIC FUNCTION 



Figure 7-1. The OEDSF Concept 
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Figure 7-2, Basic OEDSF Array Processor 

The Central Processing Unit (CPU) is the heart of the OEDSF and is specifically designed to process data 
from multiple sensors and instruments. Its elements perform medium level functions divided into three 
functional categories: 

* Algebraic (or Arithmetic) 

• Trigonometric 

« Exponential and Logarithmic 

The distribution of these elements in terms of quantity and location within the array was determined by 
analyses of the instrument processing requirement. 


The set of functions performed by the CPU is shown in Table 7-1, The cycle time of the CPU is 250 
nanoseconds; i. e. , the total time required for data acquisition, performance of ary funotion in Table 7-1 
and data output is 0. 25 microsecond. 


The OEDSF operates asynchronously with the instrument data input and its output. This capability derives 
from its input/output buffer structure and its speed which, in general, allows several OEDSF CPU cycles 
for each instrument input word. 















Table 7-1. Function Set Summary 
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The Data Base Memory structure and the Program memory structure (the control element) have identical 
architectures based on a hierarchical structure which allows both a high volume and high rates. 

The OEDSF can process the data from 20 sensors of the composite sensor B class. This calculation 
assumes an efficiency factor of 50% for the array; i. e. , programming and scheduling conflicts allow only 
50% utilisation of each array element. This is deemed a conservative figure which assumes a relatively 
weak scheduler; i. e. , utilisation of the processing elements as a function of time. 

The features of the OEDSF are summarized in Table 7-2. 

This initial design of the OEDSF considers the use of discrete logic components yielding a volume of 
approximately 1. 5 cubic feet and power requirements of 150 watts for each array. 

Advances in technology within the next two to five years will make a Large Scale Integration (LSI) imple- 
mentation feasible. Such an implementation results in the following characteristics: 

i 

g 

« 2 x 10 operations per second 

® 0. 03 cubic foot volume (1 board) 

* 3 watts power dissipation 

Further, the significantly lower cost associated with each OEDSF will allow the allocation of an entire 
matrix to each sensor with corresponding benefit in integration and test, and in programming activities. 
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Table 7-2. OEDSF Characteristics 


FEATURES 

• 20 SENSORS AVERAGE PEP ARRAY 

• REALTIME PROCESSING 

• ASYNCHRONOUS INPUT/OUTPUT 

• 250 NANOSECOND MACHINE CYCLE 

• 28, 494 AVAILABLE PIPELINES 

• 100 MEGA FUNCTIONS PER SECOND 

• MODULAR AND CASCADABLE 


ATTRIBUTES 

• SIX POINT ARCHITECTURE 

• 5X5 MATRIX CPU 

• HIEARCHIAL MEMORY STRUCTURE 

• CENTRAL LI BRARY 

• THREE GENERIC PROCESSING ELEMENTS 

• PROGRAMMABLE PIPELINES 

• WIDE BANDWIDTH 


The major consideration in the design of the OnBoard Experiment Data Support Facility was the nature of 
the implementation. Three methods of implementation are available: 

• Hardwired or Random Logic 

• Software 

• Firmware 

Each approach exhibits advantages and disadvantages with respect to sensor processing. A description 
of each area and its subsequent characteristics is discussed below. 

Software 

Software is defined as computer n ->grams which are a collection of instructions properly ordered to 
perform a particular task or set of tasks governed by a performance specification. Software is 
generally executed on a general purpose computer. 

Software possesses many characteristics that must be considered for sensor data processing. The most 
important characteristics are: 

• Complex Arithmetic Capability 

• Slow to Medium Speed 

• Invariant Hardware 
c High Flexibility 

• Dynamic System Modification 
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The high arithmetic capability exists on general purpose machines due to the register termed the accumu- 
iator. The accumulator is oapable of the primitive addition. The capability exists since all mathematical 
operations can bo decomposed or approximated by adding variables. However, the requirement to add 
results in significant speed versus complexity trade-offs. Most computers are oriented for general pur- 
pose applications over a wide range of users. Consequently, the machine is a composite of a numerical 
processor, logic processor, and communication processor without a major dominance in any specific area. 
Certain manufacturers tend to emphasize one capability over the remaining two. For example, the Data 
General Eclipse is mors numerical analysis oriented while the Digital Equipment Corporation PDP-11 is 
logic processing oriented. 

The micro computer is in reality a set of large scale integrated circuits which form a computer. The 
microprocessor is one of these components that serves as the central processing unit. The arithmetic 
capability of a typical micro computer is shown in Table 7-3. The polynomial is a second order spline as 
defined in Appendix C (Polynomial Solutions) requiring nine major macro programs. This program 
requires 1. 75 milliseconds to compute the equation: 

2 2 

P (x) = ax + bx + c 

(as shown in Figure 7-3), and 436 bytes of main memory. 

This program was benchmarked on an mteliec 8/mod 84 microcomputer. The 8080 CPU was selected 
since its general characteristics are the most oriented to numerical analysis when compared to other 
microprocessors suoh as the Fairohild F-S, The significant feature of the "microprocessor revolution" 
is that the central processing units are oriented specifically to one of the following areas: 

o Numerical Analysis 
o Control 
o Communication 

Eaoh macro as well as additional benchmark programs for other prooessrs were developed during the 
study to provide analytical metrics (quantitative measuring standards) . The progrms are listed in 
Appendix B. 

Hardwired or Andom Logic 

Hardwired or random logic is defined as a solution implemented utilizing discrete components and 
integrated circuits governed by a performance specification. 
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Any system is capable of a hardwired implementation with the following sig nif icant characteristics: 

• High Speed 

• Cost Effective at the Single Function Level 

• Programmable at the Cost of Speed 

• Hardware Dependent on the Function 

Each solution requires a fabrication effort so that hardwired devices are characterized by higher recurring 
costs. A polynomial solution identical to the polynomial solved in software is shown in Figure 7-4 as a 
hardwired approach. This solution provides a high speed solution requiring a limited number of medium 
scale integrated circuits. 

Firmware 

Firmware is defined as software contained in read-only memory. A broader definition applicable for 
this study is; Algorithms contained in random access and/or read-only memories. 



Figure 7-4. Polynomial Functional Diagram 
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This technique of increasing popularity is characterized by the following for numerical processes: 

• Software Flexibility 

• Hardv.’ are Speed 

• Significant Pre-processing 

• Not Amenable to Complex Functions 

• Algorithmic Functional Expression Required 


T < T . < 4 T 

acess _ a+b _ acess 

1100 bytes of memory 


The implementation of a polynomial utilizing this technique 
would require astronomical volumes of memory. The 
memory size equates directly to operational and physical 
characteristics as well as cost. 


These characteristics are demonstrated by the algebraic adder implemented in Figure 7-5. The firmware 
solution requires an algorithm which initially generates a set of 
partial sums. Depending on the carry generation, each stage 
may or may not alter the next higher order partial sum. 

Consequently, the addition process exhibits the following 
characteristics: 





-> ‘-i 




-+• z 


Figure 7-5. Firmware Implementation 


The software benchmark programs and the semiconductor technology forecast allowed the modeling param- 
eters shown in Table 7-3 and Table 7-4 respectively to be computed. These parameters are utilized in all 
subsequent analysis. The use of actual parameters allowed a realistic solution. 


7. 2 CENTRAL PROCESSING UNIT 

The central processing unit is a matrix of 5 x 5 processing elements which comprise programmable pipe- 
lines capable of performing three generic classes of operations as shown in Figure 7-f-. The processing 
elements are: 


• Arithmetic 

• Trigonometric 

• Exponential/ Logarithmic 
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Table 7-4. Hardware Modeling Parameters 


DEVICE 

1975 

1985 

IC'S REQUIRED 

POWER 

SPEED 

POWER 

SPEED 

MEMORY 

0.5 MW/BIT 

30 NSEC 

0.075 

MW/BIT 

25 NSEC 

64 BITS/IC 

16x16 MULTIPLIER 

LOW 

70 NSEC 

0.3 W 

50 NSEC 

4 

16 BIT ADDER 

LOW 

19 NSEC 

0.3 W 

10 NSEC 

6 

SMALL SCALE LOGIC 

0.1W 

15 NSEC 

0.03W 

8 NSEC 



4 GATES/ IC 

BINARY COUNTERS 

0. 325 W 

40 NSEC 

0.09 W 

20 NSEC 

4 B ITS/ 1C 

STEERING LOGIC 

0.2 W 

20 NSEC 


0.06W 

12 NSEC 

4 BITS/iC 


The primitive functions that the On-board Experiment Data 
Support Facility must be capable of performing are described 
in Section 4. 

Typical primitive functions are: 

• Addition 

• Multiplication 

e Compute the Sine 
a Raise a Number to a Power 





These primitive functions and their relative frequency of Figure 7-6. 5x5 Matrix CPU 

occurrence (distribution) are shown in Figure 7-7. An 

assessment of these functions was made to determine the nature and capability of each processing element. 
This phase of the CPU design is referred to as the level of decomposition; i. e. , the determination of 
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PBlHlTtVE SEMSOR DISTRIBUTION 


the level of the processing element sophistication. The 
sophistication of each processing element determines: 

• Functional Capacity 

• Programming Difficulty 

• Physical Characteristics 

• Operational Characteristics 
a Matrix Dimensions 

• Required Technology 


FUNCTION oreaATIOHS DISTRIBUTION 
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• Permissible Methods of Implementation Figure 7-7. Primitive Sensor Distribution 


The processing elements were initially investigated from a processing philosophy. At one end of the scale 
are sophisticated functions such as Fourier Transforms or Walsh functions; at the other end are simple 
additions such as performed by general purpose computers. The former approach is attractive from a 
programming point of view but require ' a very large number of specialized elements. The latter approach 
requires complex programming and is inherently slow. 


Analyses performed on the processes required by the boundary sensors showed that all processes could 
be performed by combinations of algebraic, trigonometric, exponential and logarithmic functions. The 
Algebraic (or arithmetic) function was as simple as an addition and could be complex as 2xy + z. Since 
this latter function includes the addition it was selected as the arithmetic processing element. These three 
elements are discussed in the following paragraphs. 

7.2.1 ARITHMETIC PROCESSING ELEMENT 

The arithmetic processing element (APE) is the most frequently occurring function within the array. The 
boundary sensor analysis determined that approximately 80% of the sensor processes were arithmetic. 

The primitive functions that must be performed are: 


® Addition 
« Subtraction 
e Multiplication 
« Division 
« Accumulation 


7-11 


All processes are performed on signed numbers. These functions are sufficient to allow the central 
processing unit to execute a simple unsigned addition as well as a complex two-dimensional linear trans- 
form (e.g. Fourier, Hadamard, Harr, etc.}. If each function were assigned a discrete processing element, 
the minimum contribution of the arithmetic portion of the array would be five; however, these functions are 
internally distributed as shown in Figure 7-7. The proportion of their utilization coupled to the fact that the 
least occurring function must be 1 as a minimum results in 13 processing elements being required. 

The use of discrete arithmetic functions allows for high operational speed but requires large arrays. The 
greater the number of discrete processing elements the more complex the distribution function. The 
number of arithmetic functions per second that a single processing element must execute Is given by 

j _ (Number of Operations) x (Sensor Data Rate) 
pe (Distribution Factor} x (Array Size} 

The operational rate for a single processing element executing arithmetic functions on a 5 x 5 array for 

g 

Composite Sensor B is / . (5x5, B) = 9 x 10 arithmetic operations/second, 

P e ( a ) 

The required operational frequencies as a function of array size is shown in Figure 7-8. Consequently, the 
level of decomposition will impact the array size and operational speed. The arithmetic processes may be 
realized using one of three approaches. 



Figure 7-8. Required Frequency in OPS/SFC 


1 


i 

i 

\ 

i 

* 

Approach One 

Approach one is based on utilizing three discrete arithmetic processing units such that: 

0 PE , = A + B 
a-1 - 

• PE a - 2 - A • X±1 

• PE a _ 3 - I> 

This approach requires a minimum of six processing nodes in the array. Sinee each element is programma- 
ble, six micro-instrucrions are required every machine cycle. 

Approach Two 

Approach two is a functional grouping of the primitive processes such that: 

« PE = (A + B) 

a-1 ' - ' 

• PE _ = A . X- 1 

a-2 

This approaoh reduces the required discrete processing nodes to three. This reduction not only reduces 
the array size but also the micro-instructions per machine cycle by a factor of two. 

Approach Three 

This approach groups all arithmetic functions into a single discrete processing element such that: 
e PE a = £ (A . X^ 1 + B) 

This approach results in a factor of six reduction in both array size and micro-instruction required each 
machine cycle. 

The preliminary investigation modeled each approach to establish a hardwired and software approach as 
shown in Figure 7-9. The parameters determined that a software approach is not feasible for a high-speed 
sensor data processor. The non- software solution generated the requirement for further analysis on the 
grouping effects as shown in Figure 7-10, The grouping effects analysis determined that a single 
processing element may be utilized. The advantages of the single function have been previously 
described. 
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Figure 7-9. Arithmetic Element Hardware/ Software Trade-Offs 


LEVEL 

INSTRUCTIONS 
PER SECOND 

IC'S 

ARRAY 

POSITIONS 

PROCESSING 

TIME 

ELEMENT 

RATE 

A + B, AX,£ A 

12 x 10 6 

24 

3 

210 x 10' 9 SEC 

14 x 10 6 

ax + b,Sa 

8 x 10 6 

26 

2 

190 x 10" 9 SEC 

10 x ID 6 

2(ax + bi 

4 x 10 6 

32 

1 

161 x 10‘ 9 SEC 

7xl0 6 


Figure 7-10. Arithmetic Level of Decomposition Effects 

7.2.2 TRIGONOMETRIC PROCESSING ELEMENT 

The trigonometric processing element was isolated as a single discrete element. The rationale resulting 
in a single element was that the individual functions by themselves did not constitute a sufficient drive but 
as a composite generated an acceptable load. In addition, a trigonometric function may be computed 
based on a minimum of arguments. For example, the cosine is capable of being generated by the sine. 

The trigonometric processing element was tasked to perform twelve standard functions; i.e. six forward 
and six inverse. The preliminary hardware/ software trade-off shown in Figure 7-11 dictated that the 
function generator be implemented in a hardwired or firmware solution, 

7.2.3 EXPONENTIAL/ LOGARITHMIC PROCESSING ELEMENT 

The exponential/ Logarithmic processing element was analyzed with the same rationale as the arithmetic 
processing element. Various grouping effects were studied from a hardware/software implementation 
aspect. The function is not amenable to a software implementation due to the speed of operation compared 
to the required speed of operation. The results of the preliminary hardware/software trade-off are shown 
in Figure 7-12. The grouping effects for the exponential/logarithmic functions are shown in Figure 7-13. 
The grouping effects determined that single function element may lie utilized. 
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Figure 7-11. Trigonometric Element Hardware/Software Trade-Off 
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Figure 7-12. Exponential Element Hardware/Software Trade-Off 


LEVEL 
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PER SECOND 
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Y X , e X , Inx, Log^X 

16 x 10 6 

24 

4 

45 x HT 9 SEC 

22 x 10 6 

e x , Inx 

8xl0 6 * 

18 

2 
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: 

4xlD 6 

10 

1 
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Figure 7-13, Exponential Level of Decomposition Effects 


The preliminary levels of decomposition determined that each generic class could be implemented as single 
processing elements. The preliminary analysis also established the basic machine cycle period. The 
basic machine cycle period was determined by the trigonometric processing element. This element required 
an execution time of 250 nanoseconds. Since the arithmetic and exponential/logarithmic functions reqmred 
less execution time, the trigonometric processing element established the cycle due to the pipeline concept 
dictated by Task n. 

7. 2. 4 DESIGN SELECTION CRITERIA 

The Isolation of each processing element to a hardwired or firmware solution required a set of evaluation 
criteria. 
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The criteria utilized in the design trade-off were: 


c Design Complexify 
® Flexibility 
e Capability 

• Preprocessing Requirements 

• Power 

0 Frequency 
« Physical Size 
« Weight 

Design complexity is the engineering effort required to realize a particular approach. The design com- 
plexity centered on: 

« Design Difficulty 
a Fabrication 
a Test Complexity 

The composite man-hours reflect directly into cost and indirectly into size. 

The second category is functionality. This category includes: 

e Flexibility 
© Capability 

e Pre-processing Requirements 

Flexibility is the number of functions that may be achieved utilizing the approach. For example, the 
design enables the function /^AX + B to be executed regardless of the technique. However, one design 
allows a minimum of 10 additional functions such as: 

• A + B 

a A - L 
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to be performed. An alternate design approach enables an additional eight functions to be achieved. Capa- 
bility is the ability of the design approach to assume the functions of the other generic classes. This 
parameter is important in establishing the overall capacity of the central processing unit. The final para- 
meter is the amount of pre-processing required to realize the function, e.g. table computation, argument 
pre-conditioning . 

The final category is the classical .perational parameters. The flight status of the On Board Experiment 
Data Support Facility required the.'*© parameters be given careful consideration. Significant aspects for a 
space qualified system are the power dissipation and volume. These parameters were relaxed for the 
space shuttle. 

Each design approach was modeled using the previously oomputed technology parameters shown in Section 
7.1 Table 7-4, These parameters were reflected on a scale from one to ten relative to the design para- 
meters. Three design approaches were considered for each processing element. 

o Polynomials 
© Firmware 
© Special Purpose 

The polynomial solution which is described in detail in Appendix C, is a long standing mathematic approach 
in numerical analysis. This solution required a second order spline* to be fabricated which did not appear 
feasible until recently. The technology for this approach is currently available as well as the increased 
demand for such a capability. The polynomial provides a unique approach to problem solving and is orient- 
ed to a Large Scale Integration (LSI) approach. The firmware and special purpose solutions are specific 
designs while the polynomial is a more general purpose approach. 

7.2.5 PROCESSING ELEMENT DESIGN 

The arithmetic processing element was analyzed for a polynomial, firmware, and special purpose design 
approach. The model parameters for each design shown in Figure 7-14 are based ->n the conceptual design 
shown in Figure 7-15 . The polynomial provides the maximum functionality but only intermediate signal 
processing rates. This approach requires a maximum power of almost six watts so that for large arrays 


* See Appendix C 
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PARAMETER"'"" — — 

VALUE i 

POLY 
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F'f THi 

DESIGN COMPLEXITY 
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|g||g|jj 
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WEIGHT 

SIZE 

6 W 
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0.5 LSS 
1 BOARD 

25 W 
3 MHz 
0,5 LBS 
1 BOARD 

3 W 
6 MHz 
0,5 LB 5 
1 BOARD 


Figure 7-14. Arithmetic Element Model 
Parameters 


thermal disadvantages are encountered. The firm- 
ware solution although characterized by low power 
and a medium to high functionality, exhibits a mar- 
ginal high frequency capability. All approaches 
possess a relative design complexity. The scaled 
parameters shown in Figure 7-16 determined that 
a special purpose design be utilized for the ari- 
thmetic processing element. These values al- 
though unweighted were considered primarily with 
respect to the functionality and operational char- 
acteristics, The special purpose design modeled 
at the conceptual level possessed a high composite 
score and a capability to perform 6.3 x 10 opera- 
tions per second. 


Y 



Figure f— 15 . Conceptual Design for Arithmetic 
Element 
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Figure 7-16. Scaled Parameters 


The conceptual design was further analyzed to generate the functional block diagram shown in Figure 7-17. 
The arithmetic processing element is composed of three distinct functions 

e Mnltiplier/Divider 
• Adder/Subtraotor 
« Accumulator 
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Figure 7-17. Arithmetic processing Element 

These functions are ordered to yield a capability to perform the following arithmetic functions: 


e 

X + Y 

e 

- (X + Y) 

6 

X- Y 

« 

£ (X - Y) 

* 

X • Y 

0 

£ (X * Y) 

« 

X • y" 1 

® 

£ (X • Y" 1 ) 

9 

X • Y -1 + Z 

6 

£ (X * Y + Z) 

» 

4*1 

X • Y +Z 

• 

£ (X • Y" 1 + Z) 

9 

X ■ Y- Z 

• 

£ (X • Y - Z) 

S 

X • Y -1 - 2 

e 

£ (X • Y" 1 - Z) 


The division capability is accomplished by a reciprocal multiplication- This technique computes the re- 
ciprocal of the Input variable by means of a table. The table possesses a scale factor for the multiplica- 
tion. Further, a binary scale factor utilized enables the correct quotient to be obtained without shifting. 




The trigonometric processing element was model- 
ed for three solutions with, the parameters shown 
in Figure 7-18. The parameters indicated that a 
firmware or special purpose solution should be 
considered. The polynomial although theoretical- 
ly a simple solution requires the trigonometric 
value to be computed using a power series approx- 
imation. This series possesses serious draw- 
backs as the quadrant extremes are approached. 
The scaled parameters shown in Figure 7-19 de- 
termined that a firmware solution be implemented 
for the trigonometric processes. The conceptual 
design for the firmware approach is shown in 
Figure 7-20. The processing element is composed 
of three distinct parts. 
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Figure 7-18. Trigonometric Element 
Model Parameters 


e Quadrant Analyzer 

e Argument Tables 

© Divider 

The quadrant analyzer normalizes the input vari- 
ables to a first quadrant and retains the original 
quadrant. The input argument maybe expressed 
in degrees, radians, or decimal degrees . The 
inverse parameter is a binary number. The argu- 
ment table provides the first level of conversion 
required. The divider manipulates these argu- 
ments to generate the desired functions. The con- 
ceptual design was further developed to generate 
the functional block diagram shown in Figure 7-21. 
The significant feature of this approach is the firm- 
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Figure 7-19. Scaled Parameters 



Figure 7-20. Trigonometric Element 
Conceptual Design 


ware divider. This function minimizes the need for tables and limited resolution and is economic for large 
arguments. Although the firmware solution requires large memories, current technology renders this 
approach totally feasible. This design enables the trigonometric function generator to perform the follow- 


ing: 



1 

y 


r 


t: 


L 


t 


r 

v: 


r 

tl 


n 

'> 

•-1 

l 


it 


C 

c 

fcj 


"X 

<] 

id 

r 

1 

d 

■; 

3 


7-20 




7-21 















• smx 


» SIN X 


e 

cosx 

® 

cos -1 x 








-1 






TAN'"’: 

to 

TAN X 


| VALUE | 





PARAMETER''*-*--^ 

POLY 

F7W 

K/W 




-1 

DtalGN COMPLEXITY 

240 MHRS 

170 MHRS 

23DMWS 

* 

COTAN X 

to 

COT X 
-1 







FUNCTIONAL fTY 

30 INST 

4 INST 

2 INST 

e 

COSECANT X 

e 

CSC ^X 

OPERATIONAL 








POWER 

7 Vi 

3W 

6 W 





FREQUENCY 

4 MH* 

22 MHt 

7 MH* 

n 

SECANT X 

« 

SEC X 

WEIGHT 

0.5 L.l 

0.5 LB 

0.5 L0 





SIZE 

1 0OAPO 

1 BOARD 

| BOARD 


A trade-off between the oandidate exponential/ 
logarithmic function generator models resulted in 
the design parameters shown in Figure 7-22. The 
design analysis indicated that the firmware solution 
exhibited the best properties. The significant ad- 
vantage is high speed and low power requirement. 
The scaled parameters shown in Figure 7-23 con- 
firm the firmware solution. The conceptual de- 
sign for the element is shown in Figure 7-24. The 
function generator is oomposed of two distinct 
parts ■ 


Figure 7-22, Exponential Element 
Model Parameters 
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o Logarithm Generator 
• Exponential Generator 

The exponential/logarithmie conceptual design was 
further developed to generate the functional block 
diagram shown in Figure 7-25. The functional 
block diagram provided an additional capability 
than the required natural logarithm and exponen- 
tial. This design approach provides a capability 
to perform the following functions: 


Figure 7-23. Scaled Parameters 



Figure 7-24. Conceptual Design 






















These functional diagrams were based on the requirement to; 

« Minimize Hardware 

s Maximum Flexibility 

* Maximum Operational Speed 

Each element operates internally in double precision so that trigonometric and exponentialAogarithmic 
values exceed the accuracies available in standard mathematical tables. For example, the trigonometric 
generator is capable of computing an angle to an accuracy better than an arcseeond . 

7.2.6 ARRAY SIZE 

The processing element characteristics, as well as the number and nature of the sensors that must be 
processed, provide a prime driver on the array size. The central processing unit capacity is determined 
by: 


• Number of Paths Available 

* Processing Element Characteristics 

« Operational Characteristics 

The number of available pipelines or paths is directly dependent on the permissible data flow within the 
matrix. Four permissible flows are shown in Figure 7-26. The calculations of the number of paths avail- 
able is based on a spawning technique. This spawning is described In the following manner. The number 
of paths is determined by the number of signals entering a node and the number of exits from the node. 

For example a node receives three signals which it transmits to a different node, This node receives these 
signals plus three other signals so that six paths are spawned. The number of paths spawned for various 
flow's and array sizes is shown in Figure 7-27. The addition of the diagonal flow determined that the max- 
imum permissible paths were obtained with a square array. The pathing is maximized by the presence of 
a feedback diagonal which provides the maximum mobility through the array The bi-directional flow re- 
sults in the infinite paths, The number of piths available is important during multi-sensor operations 
since it minimizes the interference between two sensors with respect to a data flow. 

The second consideration in the array size is the number of sensors that maybe processed. Assuming 
that a process is available within the desired path the number of sensors that an array can process is 
proportional to: 
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Figure 7-26. Spawning Diagrams 
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Figure 7-27. Number of Paths as a Function of Array Size and Flow Pattern 















(Array Size) (Element Rate) (Efficiency) 

Composite Sensor Rate 

The payloads versus array-size is shown in Figure 7-28. The estimated payload of 30 composite senaor B 
types dictates that a 4 x4, 5x5, or 6 x 6 array with a 250 nanosecond machine cycle sirs wiLhm the limits 
of the concept. These sizes are characterized by discrete input/output ports which may require additional 
hardware. 
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Figure 7-28. Number of Sensors Processed as a Function of Array Size and Speed 


The machine cycle period and the array size determine the number of operations per second that the array 
is capable of performing. The operational characteristics for various array sizes with various machine 
cycle periods are shown in Figure 7-29. The operational oapaoity is given by: 

I array = (Array Size > ( Eg *clency) 
y (Machine CyclB Period) 

The 5x5 array provides a data rate amenable to the anticipated needs of the On Board Experiment Data 
Support Facility, These characteristics are shown in Figure 7-30. The parameters indicate that a 5 x 5 
array is the required matrix size. The 5x5 provides the additional aspects of power and volume savings 
whan arrays are cascaded. 
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Figure 7-29. Operations/Second 
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Figure 7-30. Matrix Size Analysis 

The 5x5 array provides the following central processing unit characteristics 
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• 10 Operations/Second 
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« 28 Discrete Output Ports 


* 20 Sensor Capacity (50% Efficiency) 

7.3 MEMORY STRUCTURE 

The selected design for the memory structure is based on separate data base memory and program memory 
which are of identical architecture . The dual memory structure provides a cost-effective and high re- 
liability approach. The sensor processing requires a data base which typically contains: 

* Constants 

it Transfer Functions 
a Calculated Parameters 

The volume and nature of the data base is dependent on the specific sensor and process utilized. The data 
base requirement for the boundary and composite sensors is shown in Figure 7-31. The data buffer is the 
storage required to delay the primary and/or secondary sensor data. The nature of the buffer is discussed 
in the input/output analysis . 

The data base analysis and design was governed by evaluation of parameters which include: 

® Speed 
e Data Sources 
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Figure 7-31. Boundary and Composite Sensor Memory Requirements 



® Addressing Modes 

tt Size .■> V 

Four candidate approaches were evaluated using the result of these evaluations. 

® Data is Contained in Main Program 
9 Central Library 

* Central Library with Caches 

® Central Library w ; lh Caches and Scratch Pads 

Each approach is discussed below. 

Main. Program Contained Data, This approach requires that the micro-instruction transmitted to each 
arithmetic processing element contain the required coefficients. Consequently, a portion of the micro 
code must be reserved for these parameters whether they are required or not. This principle increases 
the program memory width by two words {32 bits) . The major disadvantage is the lack of ability tp share 
constants between processing elements, thereby resulting In a high degree of redundancy. In addition, a 
complex storage and retrieval module is required to place data-dependent constants within the program 
memory. The design complexity of the storage and retrieval is very similar to the stack or interrupt 
capability utilised on conventional digital computers . The interactive nature of the data base for sensor 
processing doeB not lend itself to a program-contained data base unless a general purpose computer is 
utilized. 

Centralized Library, The central library approach is based on a block of memory Independent of the pro- 
g-am memory that contains all data required for the processes. This approach provides the capability for 
each processing element to share common parameters. The memory size is minimized since each constant 
is stored in a single location. Further, the library may be modular allowing only the memory required for 
a given mission to be attached, minimizing the volume and power requirements. The major drawback is 
the rate at which the memory must operate. Hypothetically, each arithmetic processing element maybe re- 
quired to fetch a constant or set of constants every machine cycle. For the 6 x 5 array, the central memory 
would require a 10 nanosecond cycle time. This value is not within the current or near-term state-of-the- 
art, On tlUs basis the single centralized memory concept was rejected. 
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Central Library with Cache. Cache techniques have demonstrated their usefulness in Stochastic and 
Bayesian machines. The data base is capable of being segmented into high frequency utilization and low 
frequency utilization parameters. The cache technique is based on using a small high speed memory for 
each row or column of the CPU. The central library updates the caches with the constants on the low fre- 
quency parameters while the processing elements access the cashes. The required cycle time for the 
central library is then given by: 

_ T oycle (Machlne) 

T cycle^ Library ^ {Number of Cashes) {Words Updated /Cache) 

and the cycle time for the cache: 

T , (Machine) 

T (Cache) °y cle 

cycle' ' (Processing Elements) (Words Fetched/Element) 

For the 5 x 5 array, these parameters are 

T c ^de (Library) = 50 nanoseconds (statistical) 


and 


^cycle (C ac he) = 25 nanoseconds (worst case) 

The additional memory required for the cache is insignificant with respect to the total memory. This ap- 
proach allows constants shared in the central memory to be shared by all the processing elements. How- 
ever, data-dependent parameters are capable of being shared directly with only those processing elements 
that communicate directly with the cache in which the parameter is stored. An indirect sharing is per- 
missible by fetching the parameter from the cache and routing through the array and storing it in the de- 
sired cache. This scheme requires external feedback due to the monotonic data flow; i.e, data fetched 
from cache j can only be routed to caches j + n where j is the row or column. Finally, the library memory 
cycle is available with current technology while the cache cycle time Is within the parameters for projected 
technologies. 

Centra l i ? d Library with Cache and Scratch Pad. The centralized library with cache and scratch pad is 
both a iogloal and physical extension of the central library with a cache. This technique provides a small 
scratch pad for each arithmetic processing element. The data base is statistically partitioned such that 


KEPRODUCIBILOT of th^ 
. .mnkiAT, PAGE IS POOR 


7-30 


the cache contains the medium frequency utilized parameters while the scratch pad contains the high fre- 
quency utilized parameters. This technique provides an easy means for storing and transmitting data- 
depandent parameters. The required cycles times are 

_ T c.yel e < Ma ° hl ° e > 

* T cycle^ tjl rary ) (Number of Cache} (Words/caehe update) 

T . (Machine) 

* T cycle^ CaQ ^ e ^ (Number of Scratch Pads) (Words/update) 

T ¥ (Machine) 

_ cycle 1 ' 

® T cycle (Scratch Pad) {Words/Fetch} 

For the 5 x 5 array, these parameters are 

» T C y C | e (Library) = 50 nanoseconds (statistical) 

® T C y C i e (^ ac ^ e ) - 50 nanoseconds (statistical) 

* T C y Q ^ (Scratch Pad) = 125 nanoseconds (worst case) 

The parameters provide a realistic and feasible approach resulting in a hierarchical memory. The anal- 
ysis summary for these approaches is shown in Figure 7-32 . The analysis determined that the primary 
memory structure should be the central library with a cache and scratch pad. 

The functional block diagram for the data base memory shown in Figure 7-33 provides a scratch pad for 
each arithmetic processing element. The scratch pads are the key to the functional power. Each scratch 
pad is a two part read-while-write memory capable of being addressed by: 
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Figure 7-32. Analysis Summary 
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© processing elements 


® cache 

9 program counter 

The program memory structure shown in Figure 7-34 is identical to the data base memory structure. The 
two structures differ slightly in reality. The program memory micro instruction registers which are the 
analog of the data base memory scratch pads, are addressable only by the program caches, termed row 
controllers. Both the main memory and library are modular in nature. 

7,4 IMPUT/OUTPUT STRUCTURE 

The On Board Experiment Data Support Facility must be capable of interfacing with a wide range of sensors. 
These sensors vary in design, mission, and frequency of operation and are normally asynchronous on a 
sensor-to-senaor basis. The input/output requirements are shown in Figure 7-35 


a REQUIREMENTS 

- MULTIPLE SENSORS AT DIFFERENT FREQUENCIES 

- ASYNCHRONOUS AND SYNCHRONOUS INPUTS 

- OUTPUT DATA RATE SYNCHRONIZED TO INPUT 

- NO FILL DATA IN OUTPUT DATA STREAM 

- NO REPETITION OF DATA IN OUTPUT DATA STREAM 

Figure 7-35- Input/Output Requirements 


In addition to the varying frequency range and asynchronous relationship, the output data must be synchro- 
nized to the input data rate to maintain a continuous data flow. Based on these requirements three design 
approaches were considered; 

9 Sensor Synchronized to OEDSF 
© OEDSF Synchronized to High Frequency Sensor 
» Asynchronous Data Transfer 

Sensor Synchronized to OEDSF . The block diagram for this approach shown in Figure 7-36 is composed 
of three major components 

9 sensor 
® scaler 
® array 
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This technique requires the sensor to output data synchronously with the OEDSF. The array clock is 
sealed in a frequency divider and transmitted to the sensor. The approach simplifies the data transfer but 
requires the sensor operational frequency to be dependent on a sealed value of the array clock. This 
technique allows each array machine cycle to be optimized but requires the additional hardware (counters) 
for the soaling process. The amount of hardware required for scaling would be less than four 4-bit 
synchronous counters per port. 


OEDSF Synchronized to High Frequency Sensor. The 
functional block diagram for this approach is shown in 
Figure 7-37. This technique requires the array to be 
synchronized to the highest frequency sensor by 
means of a phase lock loop. The frequency generated 
is rescaled and transmitted to the remaining sensors 
as in the first approach. The approach synchronizes 
the system to a sensor providing a simple data trans- 
fer and machine cycle optimization. The phase lock 
loop, however, presents the major drawback for the 
design. A stable and accurate phase lock loop re- 
quires a significant design and hardware effort to 
minimize the effects of phase jitter. In addition 
Bcalars are required for the remaining sensors. 

Asynchronous Data Transfer. The conceptual design 
for the asynchronous mode is shown in Figure 7-38. 

The asynchronous transfer relaxes timing constraints 
for both the sensor and the array. The hardware 
required for this approach is minimized since only 
a single word interface buffer is required. The single 
word buffer results from the fact that the array clock 
processes many more cycles than the sensor clock; 
however, the machine cycle utilization is not optimized, 
the worst case condition being 50%. This technique 
requires a sensing circuit to determine when a sensor 
word is available. 


CLK 


-S SCALAR 


CLK 


SENSOR 


*} 


DATA 


array 


Figure 7-36 . Block Diagram of Sensor 
Synchronized to OEDSF 



Figure 7-37, Block Diagram of OEDSF 
Synchronized to Sensor 



Figure 7-38. Asynchronous Operation 
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Each approach is suitable for the On Board Experiment Data Support Facility. The asynchronous data 
transfer, however, is the most applicable since it imposes no timing constraints on either the array or the 
sensor. The ability to minimize any impact on sensor design was a paramount factor in the OEDSF design. 
The functional block diagram for an asynchronous data transfer is shown In Figure 7-39. The input struc- 
ture is composed of three major components 

• Fi-Fo Buffer 
« Register 

« Synchronizer 

The output structure is composed of three major components 
e Scalar 

• Register 

© Synchronizer 

The synchronizers detect the presence of a sensor data word or processed variable that is to ba either 
received or transmitted. The input synchronizer sets a flag on the leading edge of the sensor data clock. 



Figure 7-39. Input/Output Structure 
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The array provides a read command to the required port synchronously with the array clock. The logical 
product of these parameters allows a word to be clocked into the array register. The output synchronizer 
operates in an identical manner except that the flag is set by the logical product of the array clock and the 
output ready command. The data is strobed into the register. In each case, the flag is reset tty the active 
clock. The array clock is the active clock for the input and the scaled sensor data clock is the active clock 
for the output. 

The registers are single word registers in which the data is stored until acted upon by a clock. The scalar 
is a frequency division capability. This function is required for processes that result in a data reduction 
through processing (such as the Radiometer/Scatterometar reduction factor of SO to 1). The input sensor 
data, clock is routed to the scalar where a frequency reduction is performed . The output data rate is given by 


where N is an integer. 

Only an integer scaling rather than rate multiplication is required since the reduction is performed on a 
word basis and each word is assigned an integer count. The output of the counter strobes the register con- 
taining the appropriate variable. 

The FIFO buffer provides the data delay required in the processing of the data of certain sensors. Each 
sensor imposes a different delay requirement ranging from no delay to a full grid as with the IRS. Con- 
sequently, a modular buffer is incorporated at each input port. The asynchronous nature of First In/First 
Out Memories enhances the OEDSF-to-Sensor interface. 

All input and output circuits of the On Board Experiment Data Support Facility are standard T^L compatible. 
The inputs are buffered so that they constitute a single unit load (i.e. 2 A v @ 40 ua, 0,4 v @ 1.6 ma). The 
buffered outputs are standard active pull-up with a full fanout capability. Level shifting may be required 
external to the OEDSF if the sensor side of the sensor/array interface point is not compatible with the logic 
family. The design interface point for the array is a FIFO input. The array, therefore, is capable of 
handling either bit serial or bit parallel data stream. This capability is programmably selectable. 

7.5 BUS AMD CONTROL STRUCTURE 

The array is characterized by separate data and instruction buses . The data bus structure was discussed 
in the analysis of the Central Processing Unit. This section discusses the instruction bus. The instruction 
bus transmits the necessary control signals which enable each processing element to 


o route up to three arguments 
« receive from four processing elements 


© transmit to four processing ele ment s 
• perform a given operation 

“lie 5x5 matrix requires that 25 instructions be transmitted every machine cycle. The micro-code re- 
quired to control the inter processing and intra processing elements has been established at twenty four bits. 
The mioro-code bit allocation is shown in Figure 7-40. This coda requires four bits for data routing and 
the remaining twenty bits for processing element control. The scratch pad operation code is used only in 
the arithmetic processing elements but is assigned a reserved location in the code. 

The transmission of the micro-code from the main memory to each processing element utilizes the hier- 
archical memory structure discussed in Section 6.1. There are two approaches for the array bus structure* 

© Multiplexed 
a Disarete 

The multiplexed transmission requires a minimum of transmission lines between the row control memory 
and the instruction registers; however, the strobing of the instruction into the register requires a set of 
synchronizing strobes. Eaoh register must be strobed consecutively. This approach requires a factor of 
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Figu/e 7-40, Micro-Code Partitioning 
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5 increase in the row controller memories. The utilization of separate instruction buses increases the 
design complexity by a factor of 5 caused by the additional number of Interconnections and the number of 
memory components; however, the significant advantage of separate buses is the reduced memory cycle 
time required. The number of components is largely determined by the memory organization. Current 
and future memories are organized to have a large number of words with each word containing a small 
number of bits. 

The summary shown in Figure 7-41 led to the selection of a multiplexed bus structure. The multiplexed 
approach required the fimctional block diagram for those processing elements that possess a scratch pad as 
shown in Figure 7-42. The storage address, data baso, and indie fe select are micro controllable parts that 
are unique to these processing elements. The functional block diagram for those processing elements 
which do not require scratch pads is shown in Figure 7-43. 


APPROACH 

MINIMUM REQUIRED 
SPEED 

EXTERNAL PE 
CONNECTIONS 

MULTIPLEXED 

20 MEGA-WORD/SEC 

120 

SEPARATE 

4. OMEGA-WORD/SEC 

600 


Figure 7-41. Comparison of Multiplexed and Separate Bus Architectures 


Loading of Program into Processor . The program loading of the Onboard Experiment Data Support Facility 
is accomplished using a cassette reader and bootstrap loader. The cassette contains the machine code that 
must be stored in the OEDSF memory prior to processing any sensor data. The data contained on the 
cassette is developed by the index generation program or manually. 


The data is organized on a byte basis for the cassette and must be stored in the memory on a word basiB, 
Consequently, the data from the cassette is received by the OEDSF bootstrap loader and multiplexed to the 
proper memory locations. The organization of the data on the tape and the structure of the bootstrap loader 
are dependent on the detailed design of the program memory. For example, the instruction is partitioned 
into two major parts. The inter-element cods and the intra-element oode. These may be placed on the tape 
interleaved, multiplexed, or sequential depending on 
the detailed design of the memory. The bootstrap 
loader receives the data from the oassette reader in 
byte format and reformats the data into OEDSF words. 

This process is off-line so that relatively slow speeds 
maybe used, e.g. 9600 BAUD. The data configuration 
is shown in Figure 7-44. 
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Figure 7-44. Sequence of OEDSF 
Program Loading 
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7.6 CONVENTION ANALYSES 

Tlie On Board Experiment Data Support Facility,, like any machine, requires a binary convention, basic 
word size and processing precision. In. addition, the numerical analysis orientation requires the selection 
of an arithmetic convention. This section treats the selection of; 

o OEDSF Word Size 
® Processing Precision 
© Binary Convention 
» Arithmetic Convention 

The On Board Experiment Data Support Facility word size selection was based both on the sensor charac- 
teristics and the requirements for interfacing with external machines. The boundary sensors ranged from 
8 bit words to 18 bit words with an average of 12 bits per word. The conventional machines that would be 
interfaced to the OEDSF are likely to be computers or standard computer peripherals. These machines 
are characterised by a 16 bit word. Therefore, the OEDSF was selected as a 16 bit machine. 

Precision is the basic accuracy of computation that can be achieved without any program intervention. 

The level of precision determines the programming complexity and processing speed. The sensor pro- 
cesses are highly analytical so that the OEDSF error contribution to the process must be insignificant. 

The analysis for several modes of precision is shown in Figure 7-45. The significant aspect is the pro- 
cessing speed . This reduction for multiple levels is not a significant factor for low precision levels; 
i.e. single, double, or triple. The major drawback is the width of the required data path. A double pre- 
cision capability results in an error contribution of one part in 2 32 for the OEDSF, This contribution is an 
error of approximately 10”® per computation. The double precision mode was selected for the OEDSF. 

The numerical analysis must be performed In either a fixed point or floating point conventions . The com- 
parison of these modes is shown in Figure <-46. The Floating Point Mode is slower and characterized by 
a wide range. The fixed point is faster and characterized by less hardware . The fixed point convention 
was selected since floating point computations are possible at the macro level in the OEDSF by using the 
arithmetic and exponential/logarithmic processing elements. 
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Figure 7-45, Machine Precision Analysis 
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Figure 7-46. Comparison of Fixecl-and Floating Point Modes 

The binary convention for the On Board Experiment Data Support Facility was baaed on the comparison 
shown in Figure 7-47. The convention exhibits various properties as shown in Figure 7*48. The algorithms 
required for each approach in order to perform a simple addition show that internally a numerical analysis 
machine is best implemented using a one's complement convention. A digital discussion of binary conven- 
tions is available in "Digital Signal Processing" by Rabineer and Gold, Me Grew Hill. 

7.7 MECHANICAL CONCEPT 

Present technology utilizing discrete logic integrated circuits requires approximately 170 chips per func- 
tional element of the OEDSF. It is anticipated that exploitation of emerging technologies (such as 64K 
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Figure 7-47. Comparison of Binary Conventions 
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Figure 7-48. Properties of Binary Conventions 

memory chips) and fabrication techniques will enable each element to be accommodated on a single 9 x 10 
inch board and that an entire OEDSF array including its data base and control system will oonsist of 
approximately 30 such boards. 

This section discusses the packaging and thermal considerations associated with such a system on shuttle. 
The basic concept allows for up to 3 OEDSF arrays to mechanically and electrically interconnect. 

The basic concept assumes an external power supply which is shown in Figure 7-49. A pessimistic con- 
cept which assumes a very conservative 70 boards per OEDSF array is depicted in Figure 7-50. 
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7.7.1 OEDSP PACKAGING CONGE PT 

The Onboard Experiment Data Support Facility (OEDSF} Unit may be required to support missions in two 
areas of space shuttle environments; (a) ■within the cabin, pressurized area; (b) on the payload pallet, 
unpressurized area . To accommodate both environments, a circulating gas convection-cooled packaging 
arrangement was studied and deemed best suited to both conditions . An alternate passive, conductive heat 
sink module configuration was also studied. 

7 .7.1.1 Assumptions 


Pressurized Mounting. The following assumptions were made* (a) Gas environment around unit in pressur- 
ized area would be cool and controlled within nominal operating limits of space shuttle; (b) Acoustic noise 
level would be within acceptable limits for printed circuit boards; (c) Shock mounting of OEDSF unit would 
be desirable , 

Unpressurized Area, (a) No make up gas supply required - leak rate acceptable for short life mission; 

(b) Acoustic attenuation would be required around unit; (c; Shock mounting of unit would be required; (d) 
Radiator viewing to space {not necessarily black space) for gas cooling can be attained. 


7. 7.1.2 Requirements 

OEDSF Unit to be: (a) modular in ooncept consisting of a multiple of array units to be configured with 30 
printed circuit boards, sized for 140 (flat pack) ohips per board; (b) Use standard parts where possible; 
(c) Cooling of circuit board required . 


7 . 7 . 1 . 3 General Arr angemen t 

1. Array Unit. Using standard size chips, a circuit board was sized using a multi-layered board 
wifhflat _ pack chips assembled on each side. Circuit board was assembled in a to hlned aluminum 
box container with aluminum side plates for accessibility to boards. Boards were mounted in a 
vertical format using standard birtaher spring clip guide rails. Boards are assembled by sliding 
along guide rails and engaging electrical connectors mounted on the opposite - : ide plate. These 
connectors can be cross-wired for inter-board connection or interconnection oan be done through 
printed circuit system on this side panel. Inter array wiring will be accomplished by routing wires 
to rear face of side panel and terminating in a single row of connectors. {See Figure 7-51). Guide 
rails are mounted far enough apart to allow slots to be drilled in top and bottom faces of unit for 
passage of cooling gas flow. Gas will be drawn or blown across circuit board faces by small cir- 
culating fans . The proposed system will be by drawing the cooling gas across the circuit board 
faces {See Figure 7-52). 

2. Unit Assembly. Assembled array units are installed into a modular housing consisting of machined 
aluminum alloy sections that can be assembled into one, two or three unit assemblies by bolting in 
top and bottom sections to suit number of array units required for mission. An upper plenum will 
then be installed over completed unit, equipped with circulating fan sized to suit thermal load re- 
quired to be dissipated. Up to this point units are common to any location or mission requirement. 
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Figure 7-51. OEDSF Packaging Concept 
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Figure 7-52. Array Unit Cooling 




3, Installation - Pressurized Area. Where OEDSF units are installed within the pressurized areas 
of the space shuttle (I.e., cabin area or pallet igloo), a basic support frame structure is required 
only and units can be bolted thru 4 bolts at the shock mount points to this base structure. Here 

it was assumed that the pressurized area will be thermally controlled by an overall shuttle system 
concept and the thermal cooling for the OEDSF units can use this pressurized gas environment 
for its own convection cooling. The cooling gasses would be drawn in through the lower slots and 
across the circuit board faces and be blown out through the top to return to pressurized are environ- 
meat. 

4. Installation - Pressurized Area. Where OEDSF units are installed outside the confines of the 
space shuttle (i.e., pallet area), a special thermal acoustic housing would be required. 

a. External Arrangement, It is proposed that this housing be a pressurized container containing 
gas for short term missions, approximately seven to fourteen days, where a leak rate of 0 . 02 
pounds/day could be tolerated for a finaL pressure of S pounds/in 2 . This leak rate is con- 
servative and easily maintained. For longer missions a make-up pressurized gas bottle could 
be installed inside the thermal acoustic container housing. The housing is required to provide 
compatible acoustic and thermal environments for the array units. A basic cylindrical shape 
is proposed and construction will feature a 1-inch thick viscoelastic epoxy laminated housing. 
The sizing of the housing will be compatible with internal pressurization requirements of 
approximately 10 psi. 

The layup of the damping material (SMRD) will be of l/2 inch wide 1 inch thick strips laid up 
in a square pattern between the walls of the housing. With this concept, the double wall con- 
struction serves as a mechanism for high wall stiffness and also for temperature stabilization. 
A rough sizing indicates two 30 mil aluminum face sheets are required to provide the neces- 
sary stiffness and strength for internal pressurization. 

A thermal blanket of 1/2 inch thick insulative material will be layed up over the inside of the 
housing for thermal protection. This blanket will also help to absorb the internal acoustic 
energy, thereby preventing reverberation within the housing. No blanket will be applied over 
the upper dome of the container as this will be the thermal energy dissipating face . Tests 
and analysis performed on a three foot viscoelastic epoxy laminated acoustic cover have shown 
this type of construction to be a highly effective acoustic attenuator. A cover was constructed 
and tested using two aluminum face sheets with a viscoelastic dissipation for minimizing 
resonant frequency effects. 

Details of the test are included in the Final Report, Shuttle Payload Acoustic Cover Feasibility 
Study, GE Document No. 75SD43234, by M. Ferranti and C.V. Stable, June 23, 1973. This 
type of construction provided an overall acoustic attenuation of 20 dB with low frequency 
acoustic attenuation on the order of 30 dB. This attenuation is highly effective for the pre- 
dicted acoustic environment of the Shuttle payload bay which has its highest levels in the low 
frequency range. 

b. Internal Arrangement and Assembly. The thermal acoustic housing will be configured with a 
flat mounting base section, a cylindrical seotion and a conical domed top section. The OEDSF 
unit will be mounted to the base section thru 4 bolts attached thru the optional shock mounts 
or elastomeric dampeners. AH external electrical wiring to the unit, except for fan power, 
will be thru this base section, allowing complete check-out of unit prior to any further assem- 
bly of housing. 

The cylindrical section will then be installed over and around the unit and bolted in place with 
a pressure seal or "O" ring between mating faces . The domed section can then be installed 
containing Hie thermally dissipating surfaces and the circulating fan, again with a pressure t 
seal or 'O'* ring between mating faces. A flexible, compressible duct will interface with the 


upper plenum on the OEDSF unit during installation of the domed section. Power to the fan 
motor will be thru a connector in the domed section, eliminating any electrical connection 
across this interface during this assembly of the housing. The domed section will be a double 
skinned cone with variable lengthed radial fins assembled vertically between the conical section 
to form radial passes thru which the cooling gas will flow. Preliminary thermal analysis has 
indicated that adequate heat transfer Is provided by this design. After the cooling gas has 
passed thru this section it is left free to return in a random fashion to the under side of the 
OEDSF unit where it will be drawn back into the unit through the slotted base by the circulating 
fan. 

5. Internal Environment. The gas environment is envisioned as a nitrogen gas atmosphere at a 
pressure of 10 psi. The nitrogen ga3 would be circulated by a single fan (more than one fan 
could be installed if thermal load so indicated). The gas would be convectively and radiantly 
cooled as it flowed past and thru the top conically finned annulus section of the housing. See Sec- 
tion 7,7.2 for preliminary thermal analysis. 


7. 7.1,4 Alternate Arrangements 

An alternate configuration study was conducted using a passive thermal path for conductive cooling of the 
OEDSF unit. This method would require a known and controlled heat sink base plate for mounting of the 
unit. See Figure 7-53. 


The temperature limits would be less controlled, but could contain the temperature of the upper limit on 
the circuit board chips to the maximum operating limit of 130F . 

Thermal heat sink strips would be required on the circuit boards . (Standard systems are available and in 
common practice). Good thermal ties would he required between array units and the basic support section. 
This would require attachments at both front and back of the array unit necessitating more attachment 
fasteners. Slightly heavier end wall sections would be required to conduct heat to the mounting faces of 
the completed unit. 

The unit would be hard mounted to the base heat sink structure of the space shuttle, with thermally con- 
ductive grease between mating faces. Hard mounting of the unit would subject the circuit boards to the full 
space shuttle vibration environment. An acoustic cover or housing would be required over the installed 
unit. This housing oould be a viscoelastic epoxy laminated housing similar in construction to the pressurized 
container. 


Figures 7-40 and 7-50 depict a larger physical configuration as noted in Paragraph 7,7, 
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Figure 7-53, Alternate Arrangement 



7.7.2 PRELIMINARY THERMAL ANALYSIS 


7. 7.2.1 Constraints 


Requirements , The thermal control requirements are show in Table 7-5 . 


Table 7-5 . OEDSF Thermal Requirements 


Heat Dissipation 

- Per Card 3W - 5W 

- Per Unit 90 - 150W 

Temperature, Card Surface 70° C max 

0° C min 

Environments. The environments of OEDSP are shown in Table 7-6 for both conduction and convection 
designs , 


Table 7-6. OEDSF Environments 


Hot Cold 

Conduction Design 50° C+ -3° C* 

Convection 

Solar 1353 W/M 2 0 

- Pallet Mount Earth 66 W/M 2 0 

Albedo 72. 72 W/M 2 0 

- Pressurized Module 26° C 18° C 


‘Assumes the Auxiliary Payload Power System (APPS) as 
source of coolant. 


7. 7. 2. 2 Gas Cooled Configuration 


1. Pallet Mount. Gas cooling of the circuit boards in a pallet mounted configuration will require the 
circulated gas to absorb the heat from the cards by convection and transport the heated gas to the 
conical cover. Fins extending down from the cover will increase the surface area for connection. 
The external surface area will be coated with Silver/Teflon with an <= = 0. 80. The area of the 
cover is adequate to reject the heat dissipated by the OEDSF in the hot case. Cold case control 
is obtained by reducing the fan speed. 

The fan will supply 46 cfm of gaseous nitrogen at rated speed ( ~141 Ib/hr ,). This will result in a 
gas temperature rise of 10° C in the OEDSF (and in the radiator/heat exchanger. For a radiator 
area of 0.785 m 2 the maximum radiator average temperature will be ~ 37° C and the gas tempera- 
ture leaving the radiator will be ~47.5° C and the maximum card temperature will be 50° C. 
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Under cold case conditions the temperature of the gas leaving the radiator /heat exchanger will be 
limited to 0° C by reducing the fan speed. 

2. Pressurized Module. The cooling arrangement for this configuration will be essentially the same 
as for the pallet except that the coolant gas will be drawn from and returned to the pressurized 
module volume . 

7. 7,2.3 Conduction Cooled Configuration 

The constraints applied to this configuration are shown on Table 7-6. It will be noted that the maximum 
sink temperature for conduction to a cold plate is 50° C. This temperature assumed that APPS will he the 
source of coolant to the cold plate. This yields a maximum temperature difference {At) to the circuit 
board of 20° C. A At of 1,7° C can be expected between the cold plate and the surface of the circuit board In 
contact with the Birtcher clips. This leaves only 3° C for conduction in the board which is not considered 
acceptable. The 17° C is achieved by using 2024 aluminum for the sidewalls, 0.2" thick (At = 13 . 0° C) and 
a 0.5" width flange at the cold p'iafe (At = 2. 8° C). It is further assumed that the bolt spacing will be 2" 
and the joint filled with thermal grease. 

If the cold plate can be tied to the Experiment Heat Exchanger in the pressurised module the maximum 
temperature can be reduced to <40° C, yielding an increase of 10° C in the circuit board At to 12.5° C. This 
is considered to be less than marginal. A At of 20“ C would be considered a minimum, requiring a cold 
plate temperature of <30°C maximum. 
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SECTION S 

INDEX GENERATING PROGRAM 


The OEDSF can be programmed manually. As exemplified in Section 6, this is an easy task in the case of 
a single sensor. When many sensors are competing for the use of the OEDSF's elements, the scheduling 
of these elements becomes a tedious task which is ideally suited for computers. 

The OEDSF concept envisions a computer program, the Index Generating Program (IGP) which generates, 
off line, the microcode required to control the OEDSF in a cost-and schedule-effective manner. 

This program resides in a TBD host computer of the PDP 11/70 class. It accepts the processing require- 
ments of the complement of instruments comprising a given payload in a user oriented language and pro- 
duces the microcode directly usable by the OEDSF controller. 

The program has been conceived as a modular, growth oriented system depicted in Figure 8-1. 

The Assembler and the Simulator are the essential components of the software system. 


USER-ORIENTED 



USER 


CONFIGURATION 

GENERATOR 


— Hg> 


Figure 8-1, Index Generation Program Overview 
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The Assembler accepts the processing functions in assembly language format and generates the microcode 
directly useable by the OEDSF. The simulator applies this microcode to a simulated OEDSF and indicates 
conflicts and illegal operations. It also provides a step by step analysis of the OEDSF operation. The 
configuration generator allows changes in the make up of the OEDSF and provides this information to all 
the elements of the IGP. Configuration changes include size of the array; i,e. f 5x5, the type of elements, 
and the location of these elements in the array. 

The Simulation Data Generator produces simulated data for input to the Simulator. It also accepts data 
output from the Simulator for simulated recirculated data. 

The Compiler enables the inputs to be formatted In a user-oriented language specifically tailored for data 
processing. 

The Scheduler is the heart of the IGP which reduces the programming of the OEDSF to a trivial task. The 
data processes required for each sensor are entered serially. The scheduler assigns C -DSF elements to 
each process as a function of the resources allocated to this module; i.e., the scheduler represents an 
area of significant growth potential. It is anticipated that well over 90% of the schedule conflicts will be 
resolved by timing schedules; i.e., utilizing the vast discrepancy between the OEDSF rate and that of the 
sensors to hold (suspend) a required process for one or more cycles of the array's operation until the con- 
flict disappears. Other conflicts resolving techniques include: identity recognition, i, e. , AB = BA and 
rerouting. 

Figure 8-2 depicts the overall IGP concept. Figure 8-3 details the key segments of the IGP. 

IGP Overview. Binary, memory-image, executable code for the OEDSF processor array is generated in 
the OASYMA module. This software module is a relatively conventional symbolic assembler with a quasi- 
macro assembler capability. The primary unconventional aspects are that the word size of the executable 
code is over 1000 bits, and that time (not duration) of execution is an essential part of the source language 
syntax. 

OASYMA accepts source language statements, each statement representing an ELEMENT INSTRUCTION 
and DATA WORD (EIW and EDW), from either of two sources. The user may provide these statements 
directly in the assembler language, SPL or Sensor Process Language. In the latter case a translator or 
compiler module is required to convert SPL statements into OEDSF Assembler language. For simple, 
single-thread processes a relatively straightforward compiler module is specified, the OASPLC module. 
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For complex or multi-thread processes, another compiler module (OAPSKD) is required to resolve con- 
flicts in multi-thread processes. This module is absolutely the most complex in the entire software 
system. It must detect conflicts in the 2-dimensional OEDSF processor array surface and attempt to re- 
thread (schedule) the data flow in three dimensions, now including time, to resolve the conflict. Because 
of the similarity of this process to the "optimizing 1 1 stages of many current high-level language (FORTRAN) 
compilers, there is a tendency to view this as a "data-flow optimizing" stage to the OASPLC compiler 
module. This is not the case. Instead, the OAPSKD merely detects and attempts, heuristically, to resolve 
conflicts in TIME and SPACE for processor ELEMENTS. There are no optimization criteria and the first 
feasible solution will be accepted. There is no guarantee that any given conflict can or will be resolved. It 
will be a ripe area for future research to devise better and more efficient conflict resolution algorithms. 

The OAPSKD module must be recognized as an open-ended, evolving software effort. The OAPSKD module 
and overall OEDSF software system (OS 2 ) must provide for growth, flexibility and continuing change in the 
conflict resolution software. 

The executable code produced by the OASYMA assembler may be loaded into the OEDSF processor or 
validated using a software simulator of the OEDSF processor array (OASSIM). This simulator will perform 
a "slow-time" bit emulation of the processor array behavior during execution of the program generated by 
the OASYMA assembler. OASSIM may also be used during the hardware design stage to gain confidence in 
the performance and correctness of each processor ELEMENT. The user will usually, however, use the 
simulator output to refine assembler or Sensor Process Language programs. 

Three other utility-type software modules are required to round out the OS 2 . All three simply aid the user 
in interfacing with the previous four main software modules. 

OAEDCG allows the user to define the hardware configuration of the OEDSF array being programmed, 
Essentially, this is a high-level language interpreter which accepts descriptions of the processor ELEMENTS 
at each node and their connectivity characteristics to other nodes. 

OASSDG provides the user a way to define the simulated external environment (data flows) for the OASSIM 
software simulator to process when emulating the OEDSF processor array. 

OIDMPG allows the user to define "Identities" which the OAPSKD may invoke when attempting to resolve 
space and time conflicts for processor ELEMENTS. 

Software System Definition. The OEDSF software system (OS 2 ) consists of (TBD) OEDSF software sub- 
system (OS 3 ) modules. Each OS 3 module is a stand-alone computer program executing upon a (TBD) com- 
puter and performs one of the modular functions required to support checkout, software development, and 
operation of the OEDSF computer system. 
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The OS® modules are listed below and are defined in more functional detail in the following paragraphs. 
OS 3 Module 

Mnemonic OS 3 Module Name 


OASSIM 

OASYMA 

oasplc 

OASSDG 
OIDMPG 
OAP SKD 

oaedcg 


OEDSF Array Software Simulator. 

OEDSF Arraj’- Symbolic Assembler. 

OEDSF Array Sensor process Language Compiler. 

OEDSF Array Simulator Sensor Data Generator. 

OEDSF Identity Macro Phrase Generator. 

OEDSF Array Path Scheduler. 

OEDSF Array Element Definition Configuration Generator. 


The OS 3 modules are interfaced by a series of files. These files are listed below and are defined in more 
functional detail in the indicated text reference sections. 


OS 3 File 
Mnemonic 


OAEDEF 

OEDSF Array 

OAOBJP 

OEDSF Array 

OASIMI 

OEDSF Array 

OASIMC 

OEDSF Array 

OASIME 

OEDSF Array 

OASIMP 

OEDSF Array 

OASIMO 

OEDSF Array 

OASMAC 

OEDSF Array 

OASMAI 

OEDSF Array 

OASMAE 

OEDSF Array 

OASMAP 

OEDSF Array 

OASPLP 

OEDSF Array 

OAEDCI 

OEDSF Array 


OS 3 File Name 
Element Definition. 

Object Program. 

Software Simulator Simulated Input. 

Software Simulator Run Control Input. 
Software Simulator Error Massages. 
Software Simulator Normal Printout. 
Software Simulator Simulated Output. 
Symbolio Assembler Run Control Input. 
Symbolic Assembler Source Language Input. 
Symbolic Assembler Error Messages. 
Assembler Normal Printout. 

Sensor Process Language Prjgram. 


Element Definition Configuration Input. 
OPIMPI OEDSF Procedure Identity Macro-Phrase Input. 

OIDLEB OEDSF Identity Definition Library 
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OS 3 File 
Mnemonic 


OSPLIF 

OEDSF 

OAVPCT 

OEDSF 

QASDLO 

OEDSF 

OAPRCI 

OEDSF 

OACDLO 

OEDSF 

OASDSI 

OEDSF 

OACCLI 

OEDSF 


OS 3 File Name 

Sensor Process Language Internal Form 
Array Virtual Path Connectivity Table 
Array Source & Diagnostic Listing Output 
Path Reschedule Control Input 
Conflict Diagnostic Listing Output 
Array Sensor Data Source Input 
Array Compiler Control Language Input 


TERMINOLOGY . The terminology used throughout this report follows generally accepted standards for 
computer systems engineering. In addition, the following project-unique terms are defined helow: 


ELEMENT 
ARRAY 
NETWORK 
CYCLE TIME 


- smallest modular processor unit, corresponds to arithmetic, trig or exponential 
function generator. 

- rectangular, 2-dimensionai matrix of processor ELEMENTS. Current thinking 
places this at a 5 x 5 symmetrical structure. 

- irregular, 2-dimensional surface of ARRAYS with arbitrary data output to input 
connectivity. 

- time required for one ELEMENT to accept, execute, and prepare to accept another 
ELEMENT INSTRUCTION WORD (EIW). Current thinking places this at .25 


microseconds. 


ELEMENT INSTRUCTION WORD (EIW) - configuration of bits encoded into a digital word which directs 
the execution of a processor ELEMENT during one CYCLE TIME. Current thinking 
places this word size at 16 bits. 

ARRAY INSTRUCTION WORD (AIW) - configuration of bits encoded into a digital word which directs 
the execution of a processor ARRAY during one CYCLE TIME. Current thinking 
places this word size at 400 bits. (5 x 5 x 16) 

ELEMENT DATA WORD (EDW) - configuration of bits representing numeric information required by 
one processor ELEMENT during one CYCLE TIME. Current thinking places this word 
size at 38 bits, (2, 16-bit numbers plus G bits of addressing information to define loca- 
tion within processor ELEMENT scratch pad memory to serve as data destination). 
NOTE. This definition assumes that 1 or more EIW's, and thereby 1 or more cycle 
times, will be required to load an arithmetic function processor ELEMENT scratch pad 
memory with its required data prior to execution of the associated arithmetic EIW. 


8-7 


ARRAY DATA WORD (ADW) - configuration of bits encoded into a digital word which provides numeric 
data values to the ARRAY during one cycle time. Current thinking places this word 
size at 646 bits (17 x 38). 

QASYMA, OEDSF ARRAY SYMBOLIC ASSEMBLER. The OASYMA symbolic assembler software sybsystem 
module permits the user to conveniently specify the functional process to be performed by each processor 
element with time. Essential elements of user convenience are: 

1. ARRAY nodes may be referenced symbolically by name instead of index number pair; 

2. Processor ELEMENT definition taken from OAEDEF file instead of user input; 

3. All processor ELEMENT functions are initially defined as NO-OP (null Operation) and need not be 
referenced by user unless an explicit function is required; 

4. Once a user specifies or implies a processor ELEMENT function, that ELEMENT continues that 
function until the user explicitly specifies a new function; 

5. Numeric constant data information may be specified in binary, octal, hexadecimal or decimal 
notation; 

6. Repeating sequences of functions for a given processor ELEMENT may be specified without 
repetitive input, 

INPUT - Input to OASYMA is three data files. One file (OAEDEF) defines the topological layout of proces- 
sor ELEMENTS within the ARRAY. A second data file (OASMAI) contains the symbolic assembly language 
source statements which are to be translated into ARRAY INSTRUCTION AND DATA WORDS (AlW’s, 
ADW's). These statements will be of the form: 

node ID 

@<time> <node IDXoperation codex or > < , . , > 

numeric data 

The third file (OASMAC) contains run control commands for the OASYMA program. 

OUTPUT - Output from OASYMA is three data files. The first file (OAOBJP) is the ARRAY object 
program or ordered set of AIW's and ADW's in format suitable for loading into the OEDSF ARRAY and 
the OASSIM software simulator module. The two other files (OASMAP and OASMAE) are print-out 
oriented files to provide normal program listings of source statements and object code, and run-time 
error messages respectively. 

PROCESSING - The OASYMA module serves to translate user instructions to the OEDSF ARRAY into 
machine language AIW's and ADW's. The particular configuration of processor ELEMENTS in the 
ARRAY is provided from the OAEDEF file. OASYMA will have a catalog of operation codes and AIW 
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formats for each type of ELEMENT. The OAEDEF file then defines which type of ELEMENT is at 
each of the ARRAY nodes for any given configuration. 
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Processing of the source language statement is initiated by first initializing the state of all processor 
elements to NO-OP and then reading each source statement and immediately translating to ELEMENT 
INSTRUCTION nnri DATA WORDS (EIW's and EDW's). In general, a new source statement can be made 
at each time step for each ELEMENT. Actually, before reading new source statements for a new time 
step, all AIW’s and ADW's are initialized to the corresponding AIW r s and ADW's of the previous time 
step {or NO-OP if the first). Thus, if a processor ELEMENT is to maintain the same function role for 
several time steps, only the initial specification is made, the same function will then continue until 
explicitly changed. When reading and translating source language statements of the form: 

no-.*.. ID 

@<time><node IOXopei ation codex or ><•■•> 

numeric data 

The statement analysis algorithm can be summarized as follows: 

@ := statement delimiter (required). 

<time> := numeric quantify following @ signifies new time step. If greater than previous time 
step by two or more units, generate object code for all interim time steps identically 
to most recently generated AIW and ADW. Initialize next AIW and ADW equal to most 
recent AIW and ADW (optional, if omitted, same time step value as previous statement). 

<node 3D>:= symbolic name or index pair of form (i, j) where i and j are unsigned, non-zero inte- 
gers. Specifies ARRAY node for following operation codes and arguments, (required) 

coperation code> := symbolic or operation code for operation to be performed by the processor 
ELEMENT at the previously specified node at the specified time, (required). 

node ID := symbolic name, or index pair of form (i. j) where i and j are unsigned non-zero 
< or > integers, or a numeric constant which specifies an argument for the previously speci- 

numeric data fied operation. Every operation code has zero, one, or more such arguments re- 
quired. Number of arguments provided in type and order (sequence) with that required 
by operation code. If node ID (symbolic name or index pair), argument is to be ob- 
tained from data flow from specified node. If numeric data, specifies a numeric 
value to be made available at the scratch pad memory. Binary, octal, decimal or 
hexadecimal data may be specified by a character string from the appropriate char- 
acter set followed by (2), (8), (10) or (1G) respectively. If no (k) notation follows, 
decimal data (10) is assumed. Twos -complement negative numbers may be specified 
by inclusion of a leading minus sign (-). All numbers are integers. Scaling appro- 
priate to the data and operation code must be performed by user, (optional) 
node ID 

<...>:= repetition of < or > field as many times as required for the operation 

numeric data 

code. All characters and fields after last required argument are ignored and are 
treated as comments until the statement delimiter @ is encountered, (optional). 
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All fields within statement must be separated by a comma or one or more spaces. 


A special form of the above statement is used to specify repeated sequences of statement. The statexne’- 
form is the same but the time field is numerically less than the current time step value. This is interpreted 
to direct the assembler to previously created AlW f s and ADW's- 

PASSIM, OEDSF ARRAY SOFTWARE SIMULATION. The OASSIM is a program which simulates the execu- 
tion of a single OEDSF ARRAY and provides the user with a detailed description of the internal operations 
and data flow with time among the functional processor ELEMENTS. 

INPUT - Input to OASSIM is four data files. One file (OAEDEF) defines the topological layout of pro- 
cessor ELEMENTS within the ARRAY, the second file (OAOBJP) defines the object !t program M or 
ordered set of ARRAY INSTRUCTION WORDS (AIW's), and the third file (OASIMI) is a time-ordered set 
of numerical data representing the values of signal inputs to the ARRAY. A fourth file (OASIMC) con- 
tains run control commands for the OASSIM program. 

OUTPUT - Output from OASSIM Is three data files. One file (OASEMO) is a file of numerical data 
representing the simulated numerical output of the ARRAY. This file will be of the same time-ordered 
format as the input file {OASIMI} so that a NETWORK can he simulated by using simulated output as 
simulated input to another ARRAY. Two other files (OASIMP and OASIME) are print-out oriented files 
to provide normal step-by-step insight into array operation and run-time error messages, respectively. 

PROCESSING - Tiie OASSIM module serves as an operations simulator and non-real-time emulator of 
the OEDSF ARRAY. The particular configuration of the ARRAY to be simulated is provided from the 
OAEDEF file. OASSIM will have a variety of sub-modules simulating each possible type of ARRAY 
ELEMENT. The OAEDEF file defines which type of ELEMENT is at each of the ARRAY nodes for any 
given configuration. Knowing the ELEMENT type at each node also defines internal data flow paths. 
External data flow paths are simulated by two other data files. The OASIMI file will contain binary data 
representing simulated digital inputs which are to be used as the simulated ARRAY "inputs". The re- 
sulting simulated ARRAY data "outputs" are written to the OASIMO data files. The OASIMI and OASIMO 
data files are time-sequentially organised and are of identical format so that the "outputs" can he used 
as "inputs" to another simulation run. 

In addition to the emulation-type numeric output, the OASSIM module provides two sets of printer-for- 
matted outputs. The data file OASIME is used for printout of all anomaly or error conditions encoun- 
tered or detected during an execution of the OASSIM module. Typical of these outputs might be an error 
message that a magnetic tape had been "filled-up" with simulated output data or that an ARRAY 
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ELEMENT had been referenced without having previously been defined in the ARRAY ELEMENT Defi- 
nition file OAEDEF. 

Another printer-formatted output file is the normal execution report file. By means of run control data 
contained in file OASIMC, the OASSIM module may produce a little or a lot of output data. In the ex- 
tremes, the minimum output would be messages reflecting the start and stop-simulation events, and the 
maximum would be a time-ordered list of internal and external data values for every processor ELE- 
MENT in an ARRAY. In all cases this output is directed to the OASIMP data file for possible print-out. 

The simulation user exercises control over the execution of the OASSIM module by the contents of the 
OASIMC data file. Typically, the user will set up the length of simulated time and various printout 
options by the contents of this file. 

Once execution of OASSIM is initiated, the OASSIM module will simulate the action of every processor 
ELEMENT at every machine cycle. Since the OEDSE array is totally synchronous above the processor 
ELEMENT level, the operation of each processor ELEMENT is totally a function of the Array Control 
Word (ACW), the Array Data Word (ADW), and the data inputs from the external data sources and/or 
other processor ELEMENTS previous cycles' output. No iterative looping is required to simulate 
asynchronous data flow, and ELEMENT simulation submodules are called only once for each ARRAY 
node. 

Figure 8-4 shows the high level flow of the OASSIM module. The OASSIM module will be coded in 
FORTRAN in basically machine-independent manner. All machine-dependent functions will be coded 
in separate replaceable subroutines or function and clearly documented as to their internal operation 
as well as interface characteristics. 

OASPLC, OEDSF ARRAY SENSOR PROCESS LANGUAGE COMPILER. The OEDSF Array Sensor Process 
Language Compiler converts Sensor Process Language (SPL) programs consisting of user level sensor pro- 
cessing procedures to symbolic OASYMA assembler source format. The source language SPL is a high 
level procedure oriented language which enables the user to specify a single or multi-thread sensor process 
algorithm without regard to the internal complexity of the OEDSF machine architecture. The compiler itself 
may be implemented in a high level procedure oriented language, such as PL/1 or fortran or may he imple- 
mented using a suitable translator writing system or "compiler-compiler". The target code of the compiler 
is specified as the OASYMA source code to provide a high degree of flexibility to the users (e.g. , several 
levels of user entry into the programming system is possible). The compiler is capable of producing single 
thread procedure object code for a single procedure without interaction with the OEDSF Array Path Scheduler 
(QAPSKD), However, if more than one SPL procedure is specified in the source progrm, the object code 
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Figure 8-4. OASSIM Module Flow Chart 
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generation phase of the compilation will he suppressed until an optimized and scheduled multi-proce dure 
program is obtained. The scheduling and optimization functions are provided by OAPSKD module in con- 
junction with the normal syntax and semantics analysis and code generation Amotions of the compiler. 


INPUT - The OASPLC compiler requires three files as input for the syntax and semantics analysis 
phase of translation. The OASPLF and OAGCLI files contain the Sensor Process Language programs 
and the compile-time control statements respectively. The third OAEDEF file containing the element 
configuration information is utilized by the path generation sub-module to generate single thread paths 
through the array structure. Two additional files are shared between the compiler and the scheduler. 
The OEDSF sensor process language internal form {OSPLIF) file and the OEDSF Array virtual path 
connectivity Table (OAVPCT) file is initially built by the compiler and is modified by the scheduler. 
Both the OSPLIF and OAVPCT files are used as input files for the final phase of compilation. 

OUTPUT - The OASPLC output includes five files. The DASDLO is au output file of the source lan- 
guage input and compile-time diagnostic errors. The OASMAI and OASMAC files are the compiler 
target code file and the OASYMA assemble-time commands. The OSPLIF and OAUPCT files are util- 
ized and updated by the scheduler, prior to the object code generation phase of the compiler. 

PROCESSING - The OASPLC performs the translation of SPL procedures into OASYMA assembler 
source statements. 


Each single or mult) -thread processing specification and procedure is treated as a stand alone inde- 
pendent process and is compiled independently. The OSPLC compiler consists of the following major 
translation phases: 


« INPUT SCANNER - User SPL source statements are input from OASPLP file as character 
mode records. These character records are checked for the proper format, syntax, and key- 
words allowed in the SPL. Comment and blanks are delated from the internal symbol form. 
Each symbol in the output string of the Input Scanner is a fired length, L- ter mediate code for- 
mat acceptable to the next phase Element Analyzer. 

* ELEMENT ANALYZER - The Element Analyzer converts the intermediate code from the in- 
put scanner to the internal table form of the program. The Element Analyzer performs a com- 
plete syntax and semantic analysis of the internal program prior to generation of the OSPLIF file . 

• PATH GENERATOR - The Path Generator processes the information contained in the OSPLIF 
file and generates single thread paths through the array. The path generator utilizes configu- 
ration information contained in the OAEDEF file to allocate array processing elements in the 
data processing path on a one-to-one basis with the primitive functions defined for each pro- 
cedure In the OSPLIF file. No attempt is made by the path generator to optimize the scheduling 
of multiprocedure programs at this level, rather the path generator generates the OAVPCT 
file for subsequent conflict analysis and path scheduling by the scheduler module. 
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SOURCE AND DIAGNOSTIC GENERATOR - The Source and Diagnostic Generator provides 
the character tile output of the input source and compile-time diagnostics from each phase of 
the compilation. The compiler diagnostic output file (OASDLO) printout and the scheduler diag- 
nostic output file (OACDLI) printout provide the user with in-depth information concerning syn- 
tax, semantics and scheduling errors in the SPL source program. 

tt OUTPUT GENERATOB - The output Generator completes the generation of the object code by 
translation of the optimized and scheduled internal program and path connectivity table to the 
required OASYMA source code, which is output to the OASMAI file. 

OAPSKD, OEDSF ARRAY PATH SCHEDULER. The OAPSKD Array Path Scheduler performs the overall 
scheduling of the single or multi-thread sensor processing procedures. Each procedure requires a non- 
intersecting-processing path through the array (i. e. , no two process procedures may intersect the same 
processing node at the same time). Thus, the scheduler must weave the concurrent procedure paths through 
the array configuration in such a way that no interference between procedures can occur. The Array 
Scheduler has access to the array configuration via the OAEDEP file. 

Since the array elements are fixed, path conflicts must he resolved by the scheduler before generation of the 
output OASMAI and OASMAC files by the compiler. 

INPUT - The Array Path Scheduler requires four files as input to the scheduling process. The OAVPCT 
file contains single thread array path connectivity information, which is used in conjunction with the 
OAEDEF file by the scheduler to weave concurrent multi-sensor processing paths through the array. 

As conflicts are resolved by the scheduler the OAVPCT file is updated with new path connectivity infor- 
mation for each single thread path modifed. The OIDLIB file is utilized by the scheduler as a source of 
algorithm identities which are substituted into the internal form of the SPL procedure. The OAPRCI 
file contains user schedule eontrol commands which allows the user to directly modify the single-thread 
procedure paths or to delete procedures from the internal form of the SPL in the event of a scheduling 
deadlock. 

OUTPUT - The OAPSKD produces a single output file and modifies or updates two additional input 
files. The OACDLI file contains diagnostic information generated during the scheduling process. If a 
multi - procedure SPL program cannot be scheduled within the virtual configuration of array, the diag- 
nostic deadlock generator sub-module will provide detailed conflict diagnostics which will be used to 
determine the proper course of corrective action e.g. , delete procedures from the SPL or modify the 
virtual array configuration via the OAEDEF file. 

The array scheduler will modify either the OSPUF file or the OAVPCT depending on the scheduling al- 
gorithm used. 
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PROCESSING - The array path scheduler performs six basic functions consisting of: 
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» Conflict Analysis 
• Path Rerouting 
« Identity Recognition 
a Procedure Compression or Expansion 
» User Path Rescheduling or Procedure Deletion 
a Deadlock Diagnostic Generation 

If the array path scheduler detects a conflict in the concurrent use of an array node, the scheduler can 
attempt to reschedule a procedure via an alternate path or can initiate an identity substitution by the 
Element Rephrase Generator to compress or expand the procedure (i. e. , compression or expansion of 
a procedure will change the length and computation of the sensor processing and thus modify the path of 
the procedure in such a way as to circumvent the conflicts). After a specified number of unsuccessful 
attempts to reschedule procedures through the array has occurred the compilation will be aborted with 
the terminating path diagnostics being output to the QACDLI file for user printout. No object or 
assemble-time command files will be generated by the compiler as a result of this abortive attempt to 
schedule multiple procedures. The user may, after examination of the path diagnostics, attempt to 
reschedule by deletion of one or more procedures or by modification of the virtual array processor 
configuration via the OAEDEF file. If the OAEDEF file is modified to allow successful compilation of 
the SPL procedures, the actual array processor configuration must be reconfigured to the virtual con- 
figuration before execution of the actual procedures can take place. 

OIDMPG, OEDSF IDENTITY MACRO- PHRASE GENERATOR. The OEDSF Identity Macro-Phrase Generator 
converts identity expressions in SPL equivalent source to the internal (OASPUF) form utilized by the 
OASPLC compiler. The identities are organized in a structured file which will be accessed by the array 
path scheduler. 

INPUT - The OIDMGP accepts source inputs from the OPIMPI file. The source file is organized as 
character mode records. 

OUTPUT - The OIDMPG generates a structured identity library file (OIDLIB) containing internal form 
expressions which are used to compress or expand SPL program procedures by substitution into the 
OASPLIF file by the scheduler. 

PROCESSING - The Identity Macro-Phrase Generator utilizes a macro-expansion capability to generate 
the required internal fr^m target code. The internal form identities are organized in a structured file 
format which allows convenient access by the scheduler for Identity comparison and recognition and 
subsequent modification of the compiler OSPLIF file. 
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OAEDCG, OEDSF ABRAY ELEMENT DEFINITION CONFIGURATION GENERATOR. The OAEDCG Array 
Element Definition. Configuration Generator accepts element definition, array and inter-array connectivity 
information and generates an optimized information structure file which is used by the array compiler, as- 
sembler, scheduler and simulator in performing their specified functions. 

INPUT - The OAEDCG module accepts array element and connectivity information via the OAEDCI 
file. 


OUTPUT - The OAEDCG module produces a structured element and virtual array configuration file 
(OAEDEF) which contains the topological definition of the target array machine. 

OASSDG, OEDSF ARRAY SIMULATOR SENSOR DATA GENERATOR. The OASSDG Array Simulator Sensor 
Data Generator accepts a compact form sensor data specification and generates a time-ordered set of nu- 
merical data representing the values of signal inputs to the vii ;ual array. 

INPUT - The compact sensor data source is input via the OASDSI file. 

OUTPUT - The time-ordered numerical data is output to the OASIMI file. 
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SECTION 9 

EFFECTIVENESS OF THE OEDSP 


This section evaluates the consequences of performing the selected processes on-board, The intention of 
this evaluation is to determine the extent of the improvement of the overall system with Tespect to cost- 
effeetiveness and timeliness of data availability to the experimenter. Table 9-1 summarises the results of 
the evaluation. Section 9, 1 discusses the operational advantages of the OEDSF and its benefits which are 
not directly related to cost, such as timeliness of data availability. 

Section 9. 2 derives the cost benefits of the OEDSF by comparison with the costs of conventional (all ground) 
processing approaches. 

Section 9. 3 trades off various approaches to providing the user with an OEDSF interface during the experi- 
ments integration phase. 

9.1 OPERATIONAL ADVANTAGES 

The OEDSF realises its benefits by exploiting its unique location in both a spatial and temporal serse. This 
exploitation is enhanced by the judicious choice of the processes which it performs, and by its architecture. 

The specific benefits for each of the sensors are discussed in Sections 4, 1 and 4. 3 of the OEDSF TASK 2 
REPORT. For each of the boundary sensors, the OEDSF produces data or information ready for extrac- 
tive processing or user modeling. In each case, the processing requirements on the ground are significantly 
reduced or eliminated. 

Temporal Advantages: 

The OEDSF operates in real time. The output signals from the experiments are fed to the OEDSF as the 
experiments generate them. All ancillary data is available to the OEDSF coincident with its generation. 
Ancillary data is all data used to operate upon or characterize the experiment data. It includes the 
following: 

1. Housekeeping data which provides information on mode, status, and environment. As an example, 
the RADSCAT processing equations include the antenna housing temperature. 

2. Guidance, Navigation, and Control (GNC) data which provides information on all Shuttle locations, 
attitude, and the rate of change thereof - this data produces tlie location of observed phenomena, 
which is a requirement of ail experiments, 

3. Auxiliary information. This is information which may be produced by other sensors, for example, 
the IRS data can be used to correct ATS data for atmospherio effects; or it may be the utilization 
of ambient characteristics; for example, calibrating the ATS by measuring the sun disk. 
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Table 9-1. OEDSP Evaluation Factors 








CONVENTIONAL APPROACH 



DATA IMMEDI- 
ATELY AVAIL- 
ABLE ON (HDDT) 

DATA 

COMPRESSION 

RATIO 

ANCILLARY 

DATA 

GROUND 

PROCESSING 

ELIMINATED 

GROUND 

PROCESSING 

ADDED 

TIME 

COST PER 
MISSION 
5K 

COST OF OEDSF 
5Y5TEM 
$K 

ATS 

CORRECTED 
DIGITAL 
imagery WITH 
LAT AND LON 

NONE 

ELIMINATED 

CALIBRATION 
RADIOMETRIC 
AND GEOMETRIC 
CORRECTION 

NONE 

6 TIMES REAL 
TIME 

264 B 

163.9 

IRS 

RAW TEMPERA- 
TURE AND 
MIXING RATIO 
PROFILES WITH 
LAT AND LON 
PER GRID 

16.1 

ELIMINATED 

CALIBRATION 
CALCULATION 
OF TEMP AND 
MIXING RATIO 

FLAG CHECK 

1/8 REAL TIME 
WITH 24 HOURS 
DELAY 

30B 

18.4 

RADSCAT 

bo AND T* WITH 
LAT AND LON 

90, 1 

ELIMINATED 

CALIBRATION 
CALCULATION 
OF <7o AND T* 

NONE 

35 TIMES 
REAL TIME 

577 

17,7 

C1MATS 

SPECIE CONCEN- 
TRATION WITH 
LAT. LON. AND 
ALTITUDE 

20, 1 

ELIMINATED 

ALL 

NONE 

TBD 

432 

17.9 


If this ancillary data is not utilized in real time, it must be recorded for subsequent processing. The re- 
cording process requires a formatting and a time-tag operation of both the sensor data and ancillary data; 
the subsequent processing requires a correlation operation to "re-match" the ancillary data with the sensor 
data. Alternately, the ancillary data may be multiplexed with the sensor data so that re-correlation is 
obviated, but a more complex formatting and reformatting process is required; further, each sensor must 
duplicate the recording of this common information with a corresponding multiplicative effect on the record- 
ing burden. 

The „eal-time feature of the OEDSF provides an adaptive property to the collecting and recording of data. 
Some examples of the utilization of this property are: 

1. Inhibit recording of had data (such as cloud covered targets, or when SNR is inadequate), 

2. Select signals to be processed (or recorded) from multi-signal or multi-channel instruments based 
on criteria which may be dependent on the scene characteristics or the signal characteristics. 

3. Establish or change instrument operating mode based on characteristics of data or ambient 
conditions. 

4. Vary the rate of correction data collection based on the measured rate of change of the error 
inducing agent. 

5. Point instruments. 
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Processing the data prior to recording or transmission usually effects significant reductions in recorded 
volume. The ancillary data which need no longer he recorded often exceeds the volume of data produced 
by the low frequency (up to several kilobits per second) sensors. 

As the prime data gets converted to information, its hulk greatly diminishes. For example, the IRS raw 
data is collected in 12 bit words for each grid point in 17 channels, a total of 17,136 hits for each group of 
3 subgrids (28 points per subgrid). The output of the OEDSF is 20 temperature values and 20 mixing ratio 
values at 7 bits each for each group of 3 subgrids, for a total of 280 bits, a compression ratio greater than 
16 to 1. 

The most significant aspect of real-time processing is that the data is ready for the experimenter when the 
shuttle lands. The pre-proeessing through a central facility with its attendant queue is eliminated. 

Spatial Advantages; 

The OEDSF derives advantages by virtue of its co-location, in space, with the instruments. One obvious 
benefit is that processes common to all instruments need be performed only once. If they were performed 
on the ground, they would be repeated at each experimenter’s site, or they would be performed at a central 
facility with its attendant queue (up to one year on Sky lab). 

The major benefit lies in the sharing by the Instruments of the OEDSF 1 s set of processing functions. The 
judicious decomposition of the processes required by the various instruments yields a finite and limited set 
of basic functions which, in various combinations, satisfy the processing requirements of all the sensors. 
The level of processing capability of each member of this set is sufficiently high that the programming 
associated with their combination is simple (and inexpensive). The developmeit of such a set for a single 
experiment would be prohibitively expensive. It becomes highly cost effective, however, when several 
experiments simultaneously share the same functions. The architecture of the OEDSF (see Section 6) has 
been configured to maximize the benefits derived from these circumstances. 

Benefits as a Function of the User. On-hoard processing is not equally applicable to all experimenters. We 
have found many experimenters anxious to exploit the benefits of on-board processing described above, and 
other experimenters who were strongly opposed to any reduction of their data. The following paragraphs 
attempt to define the various users and their associated potential as on-board processing beneficiaries. 

The users of instrument data can be placed in three categories defined by their utilization of the data. Each 
category has its own set of problems, needs, and desires. 
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These three categories are defined as follows; 


1. Instrument Developer - Typically is developing an instrument or evaluating the relationship 
between the energy sensed by the instruments and the phenomenon he is trying to measure. 
Many sensors on Nimbus missions exemplify instrument developer activities. 

2. Application Developer - Works with mature instruments to develop extractive processes which 
translate data to applicable information. The Landsat series exemplifies his activities. 

3. Operational - Routinely uses remotely sensed data as an information input into his decision 
process. TIROS is an example of an operational system. 

These categories can be associated with the processing system shown in Figure 9-1. 


The Instrument Developer may want the raw data output by the instrument; in general, he prefers to have it 
pre-processed to some extent. This extent progresses from formatting to annotation, to calibration, to 
correction. 


The Application Developer wants pre-process r' data and, frequently, information extracted to some 
level which varies depending on the complexity his task and the advances he has made. 

The Operational user wants as much processing done as possible. Ideally, he wants the final answer; for 
example, the quantity of rain which will fall on Philadelphia tomorrow. 

The benefits provided by on-board processing to each of these categories are measured by different 
standards. Instrument Developers derive benefits from on-board processing because there are many 
experiments flying simultaneously. 

On-board processing has the flexibility and capability to serve each of these users and meet their require- 
ments. In general, the various categories of instrument users require greater' and greater amounts of data 
processing as the category changes from Instrument Developer to Operational user. 
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Figure Jp-1. Range of Processing Needs 
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The Instrument Developer is primarily interested in the basic electro-optical response of his sensor and 
therefore can evaluate its performance by assessing the data in its raw or nearly raw form. This raw 
data, when preprocessed such as by reformatting or the insertion of calibration factors, will enable him to 
directly determine his instrument's performance. In general, the number of instrument developers is 
relatively small and their use of the data is oft-m very similar. This situation of a few numbered users, 
coupled with similar processing requirements, is ideal for the application of standardized processing such 
as on-board processing. Further, the volumes of data which would be investigated and analyzed in order to 
evaluate the sensor's performance is generally quite small. A few well-chosen measurements compared 
with well-instrumented or calibrated test observables will provide the Instrument Developer with sufficient 
knowledge to determine the performance of his sensor. Often, based on this data, the sensor's character- 
istics are modified and the instrument is again exercised against the test observations. 

The Application Developer is concerned with determining the utility of the remotely sensed data to various 
Earth Besources or other similar applications. The satisfaction of this need consists primarily of apply- 
ing and testing various extractive processing techniques and user models. The basic data input to this 
process is generally well established and almost always preproeessed to a nominal extent. In the area 
of alternative extractive processing and user model techniques, the Application Developer requires flexi- 
bility to exercise different techniques on the data over a relatively wide range of data characteristics. 

This situation is amenable to on-board processing in two ways. First, the degree of preprocessing is 
generally well understood and standardized, thus lending itself to a routine preprocessing function; and, 
second, the various extractive techniques can often be easily implemented at least in a Low volume situation 
with a general purpose on-board processing system. 

The Operational user is characterized as a resource manager or other similar application discipline who 
has a management function to perform and will use remotely sensed data as one of several information 
sources upon which to base bis decisions. In as much as the usage of this data input is well understood aid 
relatively standardized, it lends itself well to consistent and routine processing, both preprocessing and 
extractive processing and some aspects of the user model. For any particular application, the number of 
Operational users is relatively small and the processing required of the input data is relative invariable. 

Secondary Impacts of die OEDSF. The advent of onboard processing and the method of its implementation 
creates a new environment which affects some facets of experiment development. Some examples are: 

1. The OEDSF is flight equipment. In all space systems built to date the ground equipment comple- 
has been treated as a poor second to flight equipment in the areas of planning, management, and 
allocation of resources. This pattern will not change in the foreseeable future. Data processing 
has suffered from the fact that it has been a ground process. Data processing, when performed 
on-board, will benefit from the very significant advantages accorded flight equipment. 
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2, The OEDSF requires an OEDSF programming specialist. Many experimenters' data reduction 
facilities are programmed by either the experimenter or Ms assistants. They are experiment 
oriented rather than processor oriented. The requirement for a specialist insures that the pro- 
gramming will be effected in the most efficient and economical procedure possible. 

3. Better disciplined experimenters. The effective utilization of the OEDSF requires that the experi- 
menter fully develop Ms processing requirements prior to the flight. This forces his attention onto 
matters which are usually considered secondary creating an attitude wMch often results in one of 
two situations : the experimenter omits from Ms requirements critical ancillary data and thereby 
renders Ms experiment wortMess, or he requests all the ancillary data he can tMnk of to insure 
that he will have available whatever he may subsequently need, thereby creating an unwarranted 
demand on the system. 


9.2 COST ANALYSES 

The objective of these analyses was to perform a comparison of the cost of the OEDSF end-to-end system 
versus that of conventional ground systems performing the equivalent OEDSF functions. The methodology 
used is described below. All costs given are in constant 1076 dollars. The costs of the conventional pro- 
cessing systems for the boundary sensors was deter min ed. These costs include design and development, 
hardware, and operational. Table 9-2 summarizes these cost comparisons. 


The eosts for the OEDSF were estimated. These costs include or consider the following components: 

» Design and Development and Fabric ation of 9 flight units 
© Index Generating Program 

« Programming of the OEDSF 


Table 9-2. Cost Comparison Summary For Two Missions 


Sensor 

OEDSF Processing Costs 
(Per Mission) $K 

Conventional Processing 
(Per Mission) $IC 

1. Advanced Technology Scanner 
(ATS) 

163.9 

2648 

2. Infrared Spectrometer (IRS) 

18.4 

308 

3. Radiometer /Scattero meter 
(RADSCAT) 

17.7 

576 

4. Cl MATS 

17.9 

432 

5. Composite 

28.3 

1000-3000 



e Integration with Experiments During Levels IV and V 
» Flight Costs 
e Utilisation Factor 

* Ground Equipment 

m Operation 

The cost of the OEDSF assigned to each of the boundary sensors is based on the fraction of the OEDSF it 
uses. It is further assumed that in mos* cases the OEDSF is only used at 50% of its capability because of 
programming inefficiencies. 

The results of the analyses were then extended to full payloads using the concept of the Composite Sensor 
and its relationship to the Boundary Sensors. 

9.2. 1 OEDSF COST ELEMENTS 

This section describes the determination of the costs of the various elements comprising the OEDSF cost. 

OEDSF Hardware Cost. This costs amounts to $48, 2K per OEDSF array arrived at by dividing the total 
cost of $5, 7 million to design, develop, build and sell 9 OEDSF units amortized over 250 missions in a 
10-year period and includes a 4% refurbishment cost per mission. The $5. 7 million cost is based on the 
Work Breakdown structure shown in Section 11. Details of the estimate axe contained in a separate docu- 
ment which has been provided to the NASA Technical Monitor. The requirement for 9 units is based on the 
integration schedule discussed in Section 9.3. Two units are needed for backup during levels 1 and 2 
integration. 

Index Generating Program. The generation of the index generating program of the OEDSF for use by all 
sensors has been estimated at 950K. Details of this estimate are contained in the separate document 
mentioned above. Since the program will be unchanged for any OEDSF configuration, the cost can be 
amortized over the number of sensors serviced over many years. Ten years wa 3 selected as the period 
of validity based on anticipation of growth to other technologies after that time period. In order to estimate 
the number of sensors potentially utilizing OEDSF during the next 10 year period, a sensor utilization 
model was constructed, as depicted in Table 9-3. The early portion of this model was based on the 
"Early STS Mission Plan, 1980-1982, " by Program Development Organization, NASA-MSFC. (June 1976) 
For each payload listed on the referenced mission plan, an estimate was made of the number of sensors 
potentially utilizing OEDSF. The main criteria for establishing whether a sensor is a candidate for OEDSF 
processing were the complexity of processing, data quantity, and data rates generated. Since the sensor 


Table 9-3. Sensor Model for OEDSF Utilization 


YEAR 


QTY. OF 
PAYLOADS 

QTY. OF SENSORS 
PER FLIGHT 

QTY. OF SENSORS 
USING OEDSF 

1980 

7 

AUTOMATED P/L 

N/A 



8 

10 

30 

20 


9 

AUTOMATED P/L 

N/A 



10 

8 (ASTROPHYSICS) 

24 

20 


11 

AUTOMATED P/L 

N/A 


1981 

12 

5 (PRIM. SP. PROCESSING) 

35 

2 


13 

AUTOMATED P/L 

N/A 



14 

11 LIFE SCIENCE 

50 

10 


15 

AUTOMATED P/L 

N/A 



16 

INCLUDES APPS 

5 

1 


17 

4 (MULTI-USER) 

20 

15 


18 

AUTOMATED P/L 

N/A 



19 

1 (ATL NO. 1) 

10 

5 


20 

1 (LDEFj BESS) 

N/A 



21 

7 (MULTIUSER OA) 

11 

11 


22 

AUTOMATED P/L 

N/A 



23 

1 LIFE SCIENCES 

50 

10 


24 

AUTOMATED P/L 

N/A 



25 

11 (ASTRONOMY 

20 

15 


26 

AUTOMATED P/L 

N/A 



27 

5 (PRIM. SP. PROCESSING) 

35 

2 

1982 

28 

PLANETARY 

N/A 



29 

PLANETARY 

N/A 



30 

10 (MULTIUSER) 

20 

20 


31 

AUTOMATED 

N/A 



32 

AUTOMATED 

N/A 



33 

AUTOMATED 

N/A 



34 

1 (LIFE SCIENCES) 

50 

10 


35 

INCLUDES APPS 

5 

1 


36 

1 (AMPS) 

60 

30 


37 

AUTOMATED P/L 

N/A 



38 

7 (MULTIUSER) 

15 

13 


39 

AUTOMATED P/L 

N/A 



40 

1 ATL NO. 2 

30 



41 

INCLUDES APPS 

5 

1 


~ 42 

EVAL 

30 

20 


43 

AUTOMATED P/L 

N/A 



44 

8 (MULTIUSER) 

32 

30 


45 

AUTOMATED P/L 

N/A 



46 

LIFE SCIENCES 

50 

10 


47 

AUTOMATED P/L 




48 

9 (ASTRONOMY) 

18 

15 


49 

PLANETARY 

N/A 



so 

AUTOMATED P/L 

N/A 


1983 

TBD 

26 

EST. 150 

68 

1984 


28 

161 

74 

1985 


32 

184 

84 

1986 


33 

190 

87 

1987 


31 

179 

82 

1988 


33 

190 

87 

1987 


32 

184 

84 




Total 842 










complements for many of the payloads axe not well defined, the construction of the model for determining 
programming costs necessitated projected estimates concerning the type of sensors that would be carried, 
and their characteristics. 

Projections of OEDSF utilization during the yearB 1983-1989 were made using the October 1973 NASA Pay- 
load Model, issued by the Director of Mission and Payload Integration Office, NASA-Hq. The number and 
discipline composition of the payloads for each year in the program were used in conjunction with the ratios 
of OEDSF-related sensors per payload determined from the above-mentioned analysis for the period 1980- 
1982. This approach was selected to make maximum utilization of realistic mission model data, which is 
presented in the open literature for the first three years of the Shuttle Program. 

The results of the model show that a total of 842 sensors potentially could use the OEDSF system. This 
number includes re-runs of sensors on subsequent flights, in recognition of the high probability of the 
sensor's upgrading/modification between flights as well as the growth and multiplicity of users, that will 
evolve during the sensor's history. 

On the basis of 842 sensors, the cost of general OEDSF software development is approximately 940K/842 - 
$1. IK per sensor. 

Programming of the OEDSF. This cost covers the preparation of the processing requirements for each 
sensor into a format useable by the IGP, the running of the IGP, and the loading of the OEDSF program 
memory. This effort is nominal; a value of $500 per sensor has been estimated for it. 

Integration with Experiments During Levels IV and V 

This subject is discussed in paragraph 9. 3 The costs associated with this effort include both hardware or 
software, and support personnel for operation of the OEDSF simulator equipment and its maintenance. 

The following assumptions were made: 

• Level V integration lasting 3 months requires 2 men support on a 50% basis or $14, 400. Level 
IV integration lasting 3 months requires 1 man support on a 8% basis or $1200. These costs apply 
to each experiment because they are time oriented rather than sensor complexity oriented. 

a The cost of the OEDSF simulator equipment varies depending on the processing complexity and is 

assigned to each sensor on an individual basis. 

Utilization Factor. This factor is the fraction of the OEDSF used by a given sensor. The OEDSF performs 

g 

10 operations per second. The number of operations per second used by each sensor is a function of its 
data rate and processing complexity. The utilization factor for each sensor is a function of its data rate 
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and processing complexity. The utilization factor for each sensor was derived using the data of Table 
4-4. In general, programming techniques allow each arithmetics unit cycle to perform more than one 
arithmetic operation, as described in Section 7. 

Flight Costs. It is assumed that the OEDSF is a payload subsystem rather than a shuttle facility and will 
thus be charged flight costs. Table 9-4 shows the Recommended User Cost Allocation Rates for Shuttle/ 
Spacelab Utilization from the Final Report of the Study for Identification of Beneficial Uses of Space, dated 
November 30, 1975; contract NASS-28179, and the corresponding costs attributable to flying the OEDSF. 
This table has been updated to reflect a flight cost of $20M per the NASA Preliminary Policy Directive on 
Reimbursement For Shuttle Services Provided to Civil U. S. Government Users with cover letter dated 
July 29, 1976. 

The weight of the OEDSF is estimated at 21 Kg, its volume at 0, 028 cubic meters, and its power consump- 
tion at 150 watts. Instrument operation timelines contained in the Payload Description for Sortie Payloads 
indicate that most instruments operate only a small percentage of the time. To calculate the OEDSF energy 
requirements we have assumed a very ample 80% duty cycle over a 5-day period. 

Table 9-4. Recommended User Cost Allocation Rates for Shuttle/Spacelab Utilization 


WEIGHT: 21KG , 

VOLUME: 0. 028 m 

POWER: 150W (ASSUME 80% FOR 5 DAYS) 


SHUTTLE RESOURCE UTILIZED 

RATES UTILIZED IN STUDY" 

APPLICABLE OEDSF COSTS 

UP TRANS PORT VOLUME 

$ 25, 720/CUB 1C METER 

$ 720 

UP TRANSPORT WEIGHT 

$ 203.4/Kg 

$ 4,271 

ON ORB IT ENERGY 

$ 3217/KWH 

$46,324 

ON ORB IT CREW 

$ 12048/MAN HR 

N/A 

ON ORBIT DATA TRANSMISSION 

$ 8011/MHz OF RF BANDWIDTH 

N/A 

ON ORB IT DATA PROCESSING 

$ 4.41/WORD OF EXPERIMENT 
COMPUTER STORAGE 

N/A 

DOWN TRANS PORT WEIGHT 

$374. 74/KG 

$ 7,870 

GROUND OPERATION, 
MECHANICAL HANDLING 

$ 2385/CUB 1C METER 

$ 67 

GROUND OPERATION, 

$39. 0/WOR DOF EXPERIMENT 

N/A 

ELECTRONIC HANDLING 

COMPUTER STORAGE 

$59,252 


"BASEDOW C M AVERAGE PER MISSION OPERATIONAL COST - $20 X 10 6 
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Ground Equipment. The ground equipment required by the OEDSF consists of the tape recorders at the 
receiving sites and their equivalent at the users’ sites. These equipments are also required for raw (non- 
OEDSF processed) data. They have been excluded, therefore, from the cost computations for both types of 
systems. 

Operational Costs. The OEDSF operates autonomously. Human intervention is permissible but would occur 
only as a requirement of the instruments. Thus, no operational costs are charged to the OEDSF. The 
operation costs shown for conventional ground systems are per equivalent mission. 

9.2.2 COST COMPARISONS 

This paragraph compares the costs of processing data onboard against those of processing on the ground, 
using the boundary sensors and extrapolating these results to full payloads by means of the composite 
sensor concept. 

The basis for the cost of conventional processing for each of the boundary sensors is derived as described 
in the applicable paragraphs. 

Costs were derived using the formulae shown on Tables 9-5 and P-6. The comparison requires that the 
costs be equivalent; the unit chosen for comparison was the cost per sensor per mission. This cost is 
computed straightforwardly for the OEDSF but is more difficult to obtain for conventional systems as indi- 
cated in Table 9-6 which shows the cost as a function of the number of missions to he flown by a particular 
sensor. We have thus trade cost comparisons over a range of missions as shown in Table 9-7. The 260 
missions equivalent represents an operational system and is not representative of the shuttle in an experi- 
ment carrier mode. It is used here because the ATS ground systems costs are derived from the Lands at 
Follow-on study which operates the ATS in an operational mode. It is anticipated that most experiments 
will average two flights. 

The OEDSF has been specifically designed to be cost-effective with frequently changing configurations of 
sensors flying infrequently, whereas operational systems, notably the ATS ground system costed herein, 
have been designed to be cost-effective with operational invariant payloads. In such a case, cost compari- 
sons would appear to require adjustments; however, it is clear that other systems, such as the RADSCAT 
were specifically designed for a limited number of experimental flights and that the basis for the cost of 
their ground system compares identically with those of the OEDSF and are, further, comparable with opera- 
tional systems costs when normalized for data rate and processing complexity. In other words, ground 
systems designed for limited numbers of experimental missions appear to cost approximately the same as 
those designed for operational use. The major difference, which has been reflected in the cost comparisons, 
is that the general purpose hardware, i. e. , computers, can be re-allocated to other uses in the case of 
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Table 9-5 


Coat of Using the OEDSF 


C 


T 


u 

E 


NC U ♦ C f 


+ c. + C v c 
l s p 


WHERE, 

C T ■ COST PER SPECIFIED SENSOR PER MISSION 

U - PORTION OF OEDSF UTILIZED BY SENSOR -DERIVED FOR EACH SENSOR 

E = EFFICIENCY OF UTILIZATION OF THE OEDSF -FUNCTION OF NUMBER OF SENSORS 

N * NUMBER OF OEDSF TO SUPPORT MISSION » 1 (UNIT ONBOARD) + 2/7 (BACKUP) *1.3 

C u ■ COST OF OEDSF HARDWARE - AMORTIZED COST OF OEDSF + REFURB I SHMENT 
ASSUME 25 MISSIONS PER YEAR X 10 YEARS > ^ * 28 FLIGHTS/OEDSF 

ASSUME 4% of HARDWARE COST PER FLIGHT REFURB I SHMENT COSTS 
■ ^ + 0.04XG36K ■ $4B.2K 

C f * FLIGHT COST* $59. 3K 

Cj • INTEGRATION COST * $15,600 + COST OF SIMULATOR EQUIPMENT 

C * AMORTIZED COST OF I GP ■ g4g ^ENSORS = $UK 

C * COST OF PROGRAMMING SENSOR WITH IGP BEFORE EACH FLIGHT 
P 

* $0,5K 


Table 9-6. Cost of Conventional System 
DEDICATED FACILITIES (SINGLE QR FINITE GROUP) 

S' VW f f ¥ * c o“ 

WHERE 

C T * COST OF CONVENTIONAL SYSTEM PER MISSION PER SPECIFIC SENSOR 

C H ■ HARDWARE COST 

C cs * COMMON SOFTWARE 

U * PERCENTAGE SHARE OF FACILITY USAGE 

C DS * DEDICATED SOFTWARE 

C Q • OPERATIONAL COST OF FACILITY 

F * NUMBER OF Ml SSI DNS FLOWN BY SPECIFIC SENSOR 

CO MMON SHARED FACILITIES (GENERAL PURPOSE COMPUTERS) 

C T 1 AC. * £- S 
T A F 

WHERE 

C A tS COST PER UNIT TIME FOR USE 
A IS TIME REQUIRED TO PROCESS MISSION DATA 
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Table 9-7. Data Processing Cost Comparisons as a Function of Total Missions 

OEDSF COST PER MISSION 



EQUIVALENT NUMBER OF 

conventional system 

20 

Him 

mrm 

INSTRUMENT 

MISSIONS 

COST PER MISSION 

SENSORS 


sensorsI 


(OVER 10 YEARS) 

$K 


mm 

■B 

ATS 

260 

24.0 

IB 

123.6 

123.6 


130 

44.3 

■ 

123.8 

123.8 


20 

268.0 


125.5 

125.5 


2 

2648 1 

163.9 

163.9 

163.9 

IRS 

260 

14.8 

2.6 

3.7 

5. B 


130 

17.0 

2.7 

3.8 

5.9 


20 

42,0 

3.4 

4.5 

6.6 


2 

307.5 

18.4 

19.5 

21.6 

RAD SCAT 

260 

79.4 

2.0 

2.3 

3.1 


130 

83.3 

2.1 

2.4 

3.2 


20 

125.6 

2.8 

3.1 

3.9 


2 

575.6 

17.7 

18.0 

18.8 

CIMATS 

260 

45 

2.2 

2.9 

Bl 


130 

48 

2.3 

3-0 

— 


20 

81 

3,0 

3.7 

4.1 


2 

432 

17.9 

18.6 

20.0 


experimental programs. The hardware costs have, therefore, been subtracted from the cast of these sta- 
tions. Similarly, the costs of integrating the OEDSF with the experiments at levels 5 and 4 integration are 
considered to repeat for the first two flights— thereafter, these costs are not repeated and are shown as 
prorated over the number of flights. 


ATS Cost Comparisons 

The Advanced Technology Scanner utilizes 62% of the OEDSF capabilities. This usage factor represents the 
utilized fraction of the total rate of operations that can be performed on the OEDSF; i. e. , 10 operations 
per second. The factor was determined by overlaying the set of OEDSF array instructions as each of the 
processing functions, as derived in the processing flows in Task II of the study. 

The Advanced Technology Scanner requires processing at several internal rates. Further, these processes 
are shared and are band interactive. 


For example, the location of a sample set within the data is required for each spectral band; however, the 
computation of this value for one band is used by another band. Consequently, the function is performed at 
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l/7th of the required rate. The computations for the Advanced Technology Scanner processed by the array 


are: 


1. Scan line computations 

2. Pixel computations 

3. Band- to-band computations 

The utilization does not include the geometric model computations which are normally computed in a sup- 
port processor. The low utilization factor allows this model to be computed by the OEDSF in a single array, 
dedicated to the ATS sensor. 

Table 9-8 shows some of the characteristics that were estimated in determining the usage factor for TS. 


Table 9-8, ATS Usage Factor Characteristics 


CHARACTERISTICS 

VALUE 

Scan Line Period 

2. 5 x 1Q“ 4 sec. 

Number of Operations per Line 

36 

Scan- Line Loading 

1. 5 x 10 5 ops /sec. 

Array Utilization 

0. 14% 

Operations per Pixel 

4 

Pixel Loading 

Array Utilization = PDCEL LOAD ING/OEDSF RATE - 62% 

6 x 10 7 


The ATS sensor is described in Appendix A of the OEDSF Task 1 report; its processing requirements are 
described in Paragraph 3. 1 of the OEDSF Task 2 report. The multi- spectral scanner class sensor requires 
two distinct processes— radiometric and geometric correction. The preprocessing system developed by 
the General Electric Company Space Center, Valley Forge, Pa. for the Thematic Mapper is the same 
generic system required for the Advanced Technology Scanner derived in the LandBat Follow-on study. The 
functional block diagram is shown in Figure 9-2. 

The OEDSF performs Calibration, Radiometric correction and Geometric correction in real time on all the 
data. Only those segments of the ground processor associated with these functions are considered in the 
costs. The ATS ground processor operates only on good data by editing out undesirable scenes prior to 
processing; however, it operates only on the selected scenes at a considerably reduced rate from that of 
the OEDSF. Overall, the useful data throu^nput is equivalent in that the OEDSF operates on all the data in 
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Figure 9-2. Advanced Image Processing System 
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the same time frame in which the ground system operates on selected scenes. The cost of the scene selec- 
tion portion of the ATS ground system is charged to the ground system because, although it also provides 
features not present in the OEDSF processing, it is the means by which the ground segment m aintains a 
throughput rate consistent with the input volume. 

The cost elements on Table 9-9 consider the following: 

1. Program Management - includes the project control functions of planning, scheduling, and coor- 
dinating all activity related to the development/construction of the facility. 

2. Systems Engineering/Integration - related to interface-related analysis and design efforts, and 
technical direction during portions of the prograi .. 

3. Facility Equipment includes the data processing equipment required to implement the facility. 

4. Integration and Test - encompasses those tests performed on the assembled ground processing 
system, including simulations, site integration and checkout, and training. 

5. Software Development - refers to the program development specifically tailored to the particular 
sensor. 

6. Mission Operations - covers the cost of ground operations necessary to reduce the data. 


Table 9-9. ATS Preprocessing Ground Facilities Cost Summaries 



ENG’G 

SK 

MFC AND QA 
SK 

MATT 

SK 

TOTAL 

$K 

PROGRAM MANAGEMENT 

591 



591 

SYSTEM ENGINEERING 

384 



384 

FACILITY EQUIPMENT 

400 

450 

2382 

3232 

INTEGRATION AND TEST 

348 

28 


376 

SOFTWARE DEVELOPMENT 

705 



705 

TOTAL 

2428 

'vl 

CO 

2382 

5288 

MISSION OPERATION 

943/YEAR 



943 /YEAR 


The composition of the ground operation crew is varied and includes computer technicians, maintenance per- 
sonnel, management, and user liaison personnel. The portion of the crew estimated herein considers the 
time-sharing of the various skills represented in the crew, as required to perform only the ATS data radio- 
metric and geometric corrections, and the data selection and editing. 

The corresponding OEDSF costs are summarized below using the formula given in Table 9-5. The cost of 
OEDSF simulation equipment is estimated at $24, 800, 
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C T = [1.3 (48.2) + 59.3] + 40.4 + 1.1 +0.5 = $163. 9K 

Actually, since the ATS would utilize a dedicated OEDSF the efficiency of programming would be consider- 
ably higher than 50% such that this estimate derived for multiple sensor scheduling is not applicable. In 
practice a full OEDSF array would be allocated to the ATS such that the U/E ratio would be unity. 

IKS Cost Comparison. The IRS uses 0.43% of the OEDSF capabilities. The data processing complexity is 
relatively high but the data rate of a few kilobits per second is five orders of magnitude below the OEDSF 
rate. 

The IRS sensor is described in the OEDSF Task I Report. Its data processing requirements are contained 
in the Task II Report. 

Data Routing to GISS. The IRS data (together with data from several other instruments) obtained during 
Nimbus flight is stored on the High Data Rate Storage System (IIDRSS) on-board the spacecraft for subse- 
quent play-back to ground using the S-band channel. Data from the HDRSS is routinely received at two 
Spaceflight Tracking and Data Network (STDN) stations located near Fairbanks, Alaska and Rosman, North 
Carolina. The data acquired at Alaska are recorded during the pass and then transmitted over a microwave 
link at reduced rates to the Meterological Data Handling System (MDHS) at GSFC. Data acquired at Rosman 
are relayed directly to GSFC over a wideband data link. Approximately 90% of all data are acquired by the 
Alsaslc STDN* 

The MDHS decommutates the IRS data from the spacecraft data stream and transmits it via computer-to- 
computer data link to the Goddai’d Institute for Space Studies (GISS) on an orbit- by- orbit basis. Multi-orbit 
magnetic tapes containing the same data are courier-delivered to NOAA/NESS, Suitland, Maryland, for 
developmental back-up processing and research purposes. Digitized tapes of IRS data containing calibrated, 
located radiances are produced for archiving at the National Space Science Data Center (NSSDC) at Greenbelt, 
Maryland. The total IRS data flow is summarized in Figure 9-3. 

Data Processing Requirements. The raw digital data is routinely processed at GISS using computer soft- 
ware developed by NOAA/NESS. The primary outputs are nine track, 1600 bpi magnetic tapes containing 
calibrated, located radiances. The tapes are produced using the IBM 360/195 at GISS or the IBM 360/195 
at NOAA. 
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Figure 9-3. IRS Data Flow 


The processing software consists of 6 basic computer programs whose functions are listed below: 

1. INGEST - produces located radiances 

2. ARM - calculates clear column radiances 

3. R^r- calculates temperature and mixing ratio profiles 
4„ COEFF - generates coefficient matrix 

5. SFC - performs surface analysis 

6. MULT - performs multi-level analysis. 


The processing sequence for these programs is given in Figure 9-4. 

Since the data reduction is performed using a rented system, the IBM 360/195, the cost of the software 
development is in essence the cost of the six programs enumerated above. 

The cost of the conventional processing for IRS data is shown in Table 9-10. 
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Figure 9-4. IRS Data Processing Sequence 


TabL? 9-10. IRS Processing Ground Facility Cost Summary 



COST ($K) 

PROGRAM MANAGEMENT 

50 

SYSTEM ENGINEERING 

50 

FACILITY EQUIPMENT 

RENTAL COSTS SHOWN UNDER OPERATION 

INTEGRATION AND TEST 

60 

SOFTWARE DEVELOPMENT 


PROGRAM "INGEST" 

161 

PROGRAM "ARM" 

86 

PROGRAM "RET" 

21 

PROGRAM "COEFF" 

54 

PROGRAM "SFC" 

27 

PROGRAM "MULTI" 

81 

TOTAL 

590 

MISSION OPERATION 


IBM 360/195 TIM 

10/MISSION 

MANPOWER 

2,5/MISSION 


The cost of processing IRS dat v H the OEDSF is given by the equation in Table 9-5. The cost of OEDSF 
simulation equipment is estimated ai $172. 

0 004*1 

C = — ~ [1. 3 (43. 2) + 59. 3] + 15. 8 + 1. 1 + 0. S 

T 0. o 

= $18. 45K 


RADSCAT Cost Comparisons. The RADSCAT sensor is described in the OEDSF Task 1 Report, its process- 
ing requirements in the Task 2 Report. 
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Figure 9-5 identifies the operations that must he performed by the data processing facility and the main 
hardware equipments. There are four separate operations: 


1. Conversion of the 28 track EREP PCM tapes to a 14 track equivalent 

2. Conversion of the 14 track tapes to a computer compatible format 

3. Conversion of raw RAD SCAT data to o 0 (radar baekseatter cross- section) and T ANT (radar 
antenna temperature) as a function of time and geographical position. (Housekeeping data is also 
analyzed and processed.) 

4. Generation of tabs and plots. 


The portions of the EREP data processing facility applicable to the RAD SCAT consist of the fo Lowing hard- 
ware equipment: 


1. 28 & 14 track PCM tape recorders 

2. PCMDecomm 

3. PDP-11/45 computer (2) 

4. FR-80 Micro-filmer 


The facility also includes an array processor used exclusively for pre-processing filtering of S192 data, 
and therefore, not charged against the S193. 
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Figure 9-5. EREP Processing Operations 
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Each PDP-11/45 computer is a 16 bit machine with the following 1 characteristics and peripherals: 

1. Core Size 64K 

2. Core Speed 0. 5 Microseconds 

3. 2 Discs, 10^ Words Each 

4. 4 Tape Recorders 


Figure 9-6 represents the flow chart of the S-193 RS program to process the RADSCAT data. A functional 
description of this program, excerpted from the EF.S-100-05 program definition manual, (Sec. 2,4) is as 
follows: 


The S-193 RS Program reads Radiometer/Scatterometer data from a High Density or 
9-track tape which has been constructed from a 28-track EREP tape. These data are 
comprised of status words, housekeeping data and radiometer/scatterometer data in 10- 
bit words. 

First, the control input data, such as edit parameters and output processing options input 
to the S-193 RS routine, determine what further inputs are required to fulfill the process- 
ing option requests. These requests can assume two forms: raw sensor data or processed 
sensor data in engineering units. Thus, the processing for the S-193 RS routine is divided 
into two distinct phases or data passes. Both phases, however, may process only a 
maximum of ten minutes of sensor data at any one request. These sensor data specified 
for one of the two data passes are input to the S-193 RS routine via either high density 
tape or 9-track. Because of the high data rate of the high density tape, the routine Decom 
1 is used to transfer the Sensor Data to an intermediate device, namely disk. Then the 
routine DCOM2N can successfully transfer the data from disk to core. On the other hand, 
if the input source is 9-track tape, DCOM2N can transfer the sensor data indirectly from 
tape to core. 

Within both processing phases of the sensor data from tape, either high density or 9-track, 
several processing subsets are available depending upon the requested option. It should 
be noted, though, that in both processing phases, the integrity of the data "sync", must be 
established for each frame, otherwise the data are merely bypassed for the next data 
frame. This procedure continues until valid data are found. Then the processing of the 
data as outlined below proceeds. 

If raw data tabulations or plats are desired, the raw data with any necessary data correc- 
tions are output immediately to disk for intermediate storage. There the data will reside 
until all the processing options have been exercised and then the routine DSKSUP will read 
the data for tabulation/plot processing. 

Another raw data product is the 9-track CCT containing raw S-193 sensor data in non- 
imagery universal format. The S-193 RS routine need not be exercised for this product, 
though, since the stand-alone routine RAWPRC produces this requested output. 


9-22 


All the remaining data products are produced in the second phase of the S-193 RS routine 
processing. One product is a nine-track computer compatible tape in non-imagery universal 
format. This tape, created by the routine NIMUP, contains the RAD/SCAT housekeeping 


S 193 RS 


S-193 RS PGM 
FLOWCHART 



Figure 9-6. S-193 Program 
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data in engineering units, Skylab ephemeris data, center of the sensor field of view, the 
radiometer antenna temperature and the scatter ometer backscatter coefficients. In order 
to create this tape, the raw data are first converted to engineering units by the routine 
CONVTD. Next, the subroutines SKYBET and FOVIEW are used to provide the necessary 
Skybet ephemeris data and center of the sensor field of view'. These data are then used 
in the next important step; RAD/SCAT science data processing. The subroutine MODE 
makes the discrimination whether the data are RAD or SCAT and flags the appropriate 
routine. If the data are radiometer, the routine RADANT calculates the radiometer 
antenna temperature. If the data are scatterometer, the SCATBK routine provides the 
seatterometer backscatter coefficients. When these routines have been successfully com- 
pleted, the data can be transmitted to tape. 

Concurrent with the above procedure, the housekeeping data and/or RAD/SCAT/Skybet/ 
Field of View data may be written on three disk files for later tabulation/plot processing. 
Then when all the processing options have been completed, the data retained on disk can 
be read back into core by the DSKSUP routine for tabulation/plot processing. Then the 
routine GTTAB is called if housekeeping scatterometer/radiometer or Skybet/Field of 
view tabulations are desired. If plots are desired, GTPLOT is called. 


The cost estimate for the portion of the EREP data processing facility utilized by the RADSCAT sensor is 
shown on Table 9-11 and the hardware and general purpose software costs have been allocated accordingly. 
The estimate is based on 20% utilization of the EREP data processing facility used by RADSCAT. The mis- 
sion operations cost, Item 6, is based on RADS CAT’s 20% utilization of 30- person ground facility staff. 

EREP tapes containing RADSCAT data recorded on Skylab flights were returned to the EREP data pro- 
cessing facility at JSC for processing. The operations performed on the RADSCAT were of a specialized 
nature requiring either hardware of software not normally available to RADSCAT data users. 


Table 9-12 illustrates the amount of RADSCAT data collected on the three Skylab missions and the time 
required for processing this data. 


Table 9-11. RADSCAT Skylab Ground Facility Cost Summary 



ENG'G 

MAT 'L 

TOTAL 

PROGRAM MANAGEMENT* 

100 " 


100 

SYSTEM ENGINEERING* 

80 


80 

FACILITY EQUIPMENT*. 


180 

180 

INTEGRATION AND TEST* 

360 


360 

SOFTWARE DEVELOPMENT* 

460 


460 



1 1 

“ 

TOTAL 

MISSION OPERATION* 

1000 

75.6/MISSION 

180 

1180 


* PRORATED ON BASIS OF 207. OF TOTAL FACILITY AND OPERATIONS EXPENDITURES 



Table 9-12. RADSCAT Data Summary 


MISSION 

NO OF 

RADSCAT 

PASSES 

NO. OF 
TAPES 
TOTAL/ 
RADSCAT 

RADSCAT 
DATA SEGMENTS 
(TIME SLICES) 

TOTAL 
DATA 
** TIME 
SEC, 

AVERAGE MISSION * 

SEGMENT PROCESS 

TIME TIME HRS 

SEC. /MIN. MIN. /MAX. 

Skylab 2 

13 

4/2 

64 

6546 

( 2 Hrs ,) 

102/1,7 60/80 

Skylab 3 

28 

6/3 

111 

13818 
( 4 Hrs.) 

124/2 120/160 

Skylab 4 

40 

10/5 

141 

22953 
( 6 Hrs.) 

163/2.7 180/240 

* Does not 

include time for 28/14 TRACK TAPE conversion (1 day delay added) 


* 3 shift operation (complete reprocessing of S/L#2 & 3 because of various errors) 

** RADSCAT data was recorded on 50% of PASSES 


The RADSCAT uses 0. 15% of the OEDSF capability. This low percentage is due to its low data rate and 
simple processing requirements. The cost of processing RADSCAT data using the OEDSF is determined 
from the formula described earlier. The cost of materials assumed for simulation is $100. 


J T 


^S ' 015 [(1. 3> (48. 2) + 69, 3 j 


+ 15.7 + 1.1 + 0.5 


C T = $17, 67K 


CIMATS Cost Comparisons 

The CIMATS sensor is described in the OEDSF Task 1 Report; its data processing in the Task 2 Report. 
The block diagram of the overall ground data system is illustrated in Figure 9-7. CIMATS interferogram 
data is transmitted from the spacecraft to a ground station as a PCM signal multiplexed with other sensor 
signals. CIMATS data and its related ancillary data are extracted from the PCM recorded tape, merged 
on a time basis with ephemeris data, and recorded on a computer compatible tape in a designated format. 
At the user facility CIMATS interferogram data is analyzed for its gas constituents using a correlation 
technique based on a set of calibration interferograms derived from ground testing. 


Central Facility 

The central facility, based on the concept of the EREP facility, consists of special hardware for playback 
of the time annotated multi sensor PCM tape and a computer (expected to be a 16 bit mini -computer) for the 
sensor decommutation and ephemeris merging functions. The computer has appropriate I/O and auxiliary 
memory devioes to support these data processing operations, and a set of programs to execute them. The 
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Figure 9-7. CIMATS Data System 

specific functions performed by these programs are shown in Figure 9-8. In addition to these specific 
functional programs, a set of general purpose programs are required to perform overhead functions. 

During execution of the decommutation function, temperature and cloud cover sensor data, derived from 
other S/C sensors, must also be provided to aid in the gas constituent analysis program. 

Cost of mission operations is based as in the EREP case on a 10% allocation of a 30 men crew during data 
processing. 

In addition the central facility appropriately flags tape playback data that fails to pass validity checks. This 
alerts the CIMATS user to data of questionable quality. 

User Facility 

The processing operations, perfc'Tned on CIMATS data to identify the type and concentration of gas pollutants, 
are shown in Figure 9-9. CIMATS interferogram data may be taken in either the vertical nadir mode or the 
tangential limb mode. In both modes an interferogram consisting of 58 samples is analyzed by using sets 
of gas correlation tables unique to each target gas. The results designate the type and concentration of 
each of nine gas species as a function of location for the nadir mode, or of altitude for the limb mode. 
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Figure 9-8. Central Facility Data Functions - CIMATS 
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Figure 9-9. User Facility Data Functions - CIMATS 


Because the resolution of the CIMATS fore-optics is by nature relatively low (sensor field of view is 21 x 21 
miles minimum at an earth-centered altitude of 4600 miles), the precision and resolution afforded by floating 
point arithmetic are not a requirement for the location and altitude computations. Correspondingly si've 
each of the 58 samples of an interferogram is represented by a 12 bit digital word, the computations 
associated with the correlation integral also do not demand floating point arithmetic. Therefore even 
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a 16 bit minicomputer with only a fixed point arithmetic capability is suitable to execute the CIMATS pro- 
gram. However if ephemeris data is presented in a floating point format to the central facility, it would 
be more appropriate for the user to maintain that format and to program for a computer with floating 
point arithmetic. 

Because of the relatively narrow path coverage of the CIMATS sensor and correspondingly because of the 
relatively long period of time required for sensor coverage of a selected area, the results of the gas 
analysis are best presented in a tabular form rather than in a map overlay format. Typically the format 
of the tabular listing would contain columns for time, lo o atiou/ altitude, and the nine target gases. 

Two complementary facilities were costed for CIMATS: 

1. A CENTRAL FACILITY, where general pre-processing operations are performed. These opera- 
tions, common to several users, require hardware and software not normally available to CIMATS 
users. It is assumed that CIMATS would use 10% of this facility, 

2, A USER FACILITY, where the data is evaluated, and where the processing parameters are adjusted 
and the experiment results interpreted. 

The costs associated with these facilities are shown in Table 9-13, 

The CIMATS uses 0. 26% of the OEDSF capabilities. The cost of the OEDSF simulation equipment is 
estimated at $100. The cost of processing CIMATS data with the OEDSF is given by the cost formula 
described earlier. 

.3^ +15.7 + 1.1 + 0.5 

= $17.93 

Cost Comparison of the Composite Sensor 

The composite sensor has been defined in Section 5. 

Since this sensor is hypothetical in that it is an average of many sensors there is no specifiable set of 
ground equipment for its data processing. The costs of conventional processing for the composite sensor 
were therefore derived from those of the boundary sensors by comparison of data rate, processing 
complexity and analysis of the cost elements in the facilities of the boundary sensors. 

The most common approach to ground data processing is by means of general purpose computers. The 
data is pi’ocessed in non-real time, therefore the data rate impacts only the quantity of data to be 


$0.0043 

0.5 


(1.3) (48. 2) + 59 


Table 9-13. CEVIATS Ground Facility Cost Summary 



CENTRAL FACILITY 

USER FACILITY 

TOTAL 


ENG'G 

MAT'L 

TOTAL 

ENG'G 

MAT'L 

TOTAL 


PROGRAM MANAGEMENT* 

50 


50 

5 


5 

55 

SYSTEM ENGINEERING* 

40 


40 

5 


5 

45 

FACILITY EQUIPMENT* 


90 

90 

100 

100 

200 

290 

INTEGRATION AND TEST* 

180 


180 

20 


20 

200 

SOFTWARE DEVELOPMENT* 

230 


230 

150 


150 

380 

TOTAL 

500 

90 

590 

280 

100 

380 

970 

MISSION OPERATION* 

38 /MISSION 


4/MISSION 


42/MISSI0N 


* PRORATED ON BASIS OF 10% OF TOTAL FACILITY AND OPERATIONS EXPENDITURES 


processed. The major costs in such a system are the programming effort (software) and the operation. 
Computer use charges are small unless the quantity of data and the processing complexity require sub- 
stantial time on a large machine. 

The processing complexity of the composite sensor is approximately equal to that of the boundary sensors. 
Its data rate is almost two orders of magnitude higher than the 3 lowest rate sensors and almost two orders 
of magnitude lower than that of the ATS. Accordingly, we have assigned a range of cost to this system 
caused by variations in the operational and computer utilization costs which depend on the quantity of 
data processed. The lower limit of this range is the average of the lower cost boundary sensors 
facilities; i. e. , $1 million. The upper range is 3 times this amount. 

The cost of processing the composite sensor on the OEDSF is determined using the formula in Table 9-5. 
The utilization of the OEDSF by the Composite sensor is 2, 5%. The cost of the OEDSF simulation equip- 
ment is assumed to be $5000. 


The onboard processing cost is therefore*. 
0. 025 


C T .5 


C T - $28. 3K 


(1.3) (48.3) + 59.3 + 20.6 + 1.1+ 0,5 


Tr?.: 
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9. 2. 3 EXTRAPO LATION TO FULL PAYLOADS 

A full payload consists of approximately 20 oomposite sensors. This considers only instruments of 
interest to the OEDSF. This number already assumes the 50% efficiency factor of the OEDSF. The total 
data rate of this payload is 3. 8 megabits per second. The cost of processing these sensors onboard 
by the OEDSF is given by: 

C T = <1. 3) {48, 2) + 59. 3 + (20) (20. 6) + 20 (1. 1) + 20 (0. 5) 

= $65. 96K per mission. 

The comparable conventional ground systems cost would range between $20, OOOK and $60, OOCK plus their 
operational costs. 

9. 2. 4 TDRS LINK COST CONSIDERATIONS 

The preceding analyses have not considered cost savings effected by bandwidth reduction. The additional 
communication load imposed by the higher data rates required in the ground processing approach has an 
impact on TDRS system cast. For the purposes of this study, the total cost of the TDRS system over a 
given period is distributed among its users in direct proportion to the amount of data (i. e. number of bits 
relayed to the ground). This simplified approach does not factor in other services of the TDRS, such as 
tracking and relaying of analog data. The TDRS system capabilities considered are: 

« 20 Multiple-access channels at 50 Kbps: 1 Mbps total 

« 2 Single Access S-Band access channels at 6 Mbps: 12 Mbps total 

® 2 Single Access K-Band access channels at 300 Mbps: 600 Mbps total 

The cost of the TDRS system is best expressed in terms of the lease cost to NASA, according to the 
currently proposed agreement between the selected TDRS manufacturer and the Government. The cost of 
leasing the TDRS has not been established; however, a figure of $80 million is generally accepted as an 
.approximate lease fee during the early portion of the TDRS operational program. 

It was assumed that l/8th of the total TDRS cost would be apportioned to the multiple access users, and 
the remainder to the higher data rate single users. This portion, although arbitrary, is based on several 
iterations to arrive at an equitable cost breakdown that considers the per-channel service cost as well as 
the bandwidth requirements attendant to that service. On this basis, and assuming an 80% duty factor 
(due to TDRS occultation), the casts axe as follows: 

® MULTIPLE ACCESS CHANNELS: $3. 0 x lo“ 7 per bit 

e SINGLE ACCESS CHANNELS: $4. 72 x 10~ 9 per bit 

9-30 


The impact of this cost can be illustrated by application to a high data rate instrument such as the ATS. 
Each hour of transmission of the ATS data costs: 

120 x 10 6 bits/sec x 3600 sec/hr x 4, 72 x 10 9 $/bit 

= $2039 

9.3 LEVEL IV/V INTEGRATION 


Checkout and Simulator Requirement 

Experiment test and checkout during the final stages of design and development is variously referred to 
as acceptance testing, verification testing, or Level V integration. At this time simulations or represen- 
tations of Shuttle/Spacelab interfaces (physical, functional, operational) are required, including those of 
OEDSF when it is utilized. Similar interface simulations are needed when experiment equipment is com- 
bined into payload subassemblies (Spaeelab racks or pallets) during Level IV integration. Figure 9-10 
illustrates OEDSF and Spaeelab C&DM simulation requirements for Level IV/V integration. 



Figure 9-10. Level IV/V Simulation Requirements 
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Spacelab flights begin in mid-1980 and build up to a level of about one per month in 1982. Figure 9-11 
shows the current spacelab flight schedule through 1982 and summarizes Level IV/V operations required 
to support this schedule. The following assumptions are made: 

1. Level IV integration takes 3 months starting 6 months prior to launch 

2. Level V integration takes 3 months starting 9 months prior to launch 

3. There are 15 experiments using OEDSF on each Spacelab flight 

Allowing for variations in experiment checkout requirements and reflecting worst case Level IV integration 
requirements, the user trends on the lower portion of Figure 9-11 have been developed. The curves show 
that OEDSF must support Level V checkout of a few experiments starting in mid-1979 and must be able to 
support checkout of 45 experiments at any given time by late 1981. OEDSF must support a single Level 
IV integration effort in early 1980, two simultaneous efforts starting in late 1980, and three efforts at 
any given time from mid-1981 on. 

Simulator Alternatives 

Current planning for the Spacelab C&DM System has identified these approaches for integration support: 

A hardware simulator, a software simulator, or a characteristics list. OEDSF can consider these same 
approaches plus using actual flight hardware, and, in addition, can offer full or partial capability in a 
hardware simulator, C&DM and OEDSF approaches are shown in Table 9-14 along with OEDSF alternatives 
for Level IV /V integration using various combinations of approaches. Fifteen OEDSF alternatives are 
identified, using the ground rule that Level IV checkout will utilize the same or greater capability than 
Level V. 

Rationale and Comparison 

The five OESDF approaches have the following characteristics and requirements: 

1. FLIGHT HARDWARE - Sufficient quantities of flight units to support up to 48 simultaneous Level 
IV/V integration efforts. 

2. FULL OEDSF SIMULATOR - A full capability OEDSF simulator incorporating all flight unit 
capabilities and interfaces without the high level of documentation, quality control and ground 
handling restrictions that pertain to flight hardware and will include non-flight elements that are 
identical to flight OEDSF elements using non-high reliability parts. 

3. PARTIAL OEDSF SIMULATOR - Reduced version of full capability OEDSF simulator with hardware 
capability and applicable micro code for integration needs. Allows the equivalent of one full 
simulator configuration to service several users at the same time. This can be effected by 
supplying the experimenter a limited quantity of OEDSF processing elements with a vestigial 
control system. 
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Figure 9-11. User Requirements 














































Table 9-14. Simulator Alternatives 


SPACELAB C&DM SYSTEM 


OEDSf 

1 . 

Hardware Simulator 

1 . 

Flight OEDSF 

2. 

Software Simulator 
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3. 
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4. SOFTWARE OEDSF SIMULATOR - Software routines adaptable to all identified user computer 
systems allowing user in-house equipment to simulate OEDSF compatibilities at less than real 
time speeds. An attractive approach is to develop a translator program which would convert 
the microcode for the experimenter's own computer. Since the microcode controls a relatively 
small set of functions this approach is both efficient and inexpensive, 

5. OEDSF CHARACTERISTICS PACKAGE . A document consisting of detailed OEDSF operating 
characteristics and design information sufficient to allow users to model the flight OEDSF on 
their in-house computer systems. 


Each one of these approaches are analyzed for their benefits and costs relative to Level IV and V utilization. 
The rationale for the individual ratings is provided on the evaluation sheets (Table 9-15 through 9-19). The 
following values were assigned for individual ratings. 


BENEFITS 


COSTS 


Excellent - 4 

Good = 3 

Fair = 2 

Poor = 1 

Very Poor - 0 


Very High - 0 

High = 1 

Medium = 2 

Low = 3 

Very Low = 4 


An inverse rating was utilized in cost to allow direct addition of benefit and cost factors. 
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Criteria 


The criteria for evaluation were broken down into two basic areas; Benefits and Costs. Five key areas 
of benefits were identified to accommodate a broad range of subjective evaluation of the optional approaches. 
Costs were divided into initial development and continuing level of effort categories to allow for a total 
cost evaluation. The table below contains the definitions of the evaluation criteria. 


EVALUATION CRITERIA DEFINITIONS 


BENEFITS 


COSTS 


FIDELITY - Elements of speed and accuracy relative to flight unit capabilities 

SUITABILITY - Capabilities, flexibility and adaptability of the OEDSF Supplied 
Element relative to Level IV and V integration and test needs 

USABILITY - Constraints, controls and complexities placed on the User by 
interface requirements of the OEDSF supplied element 

RELIABILITY - Equipment Interaction and Data Interpretation/Preeision hehveen 
User Equipment and OEDSF supplied element 

AVAILABILITY - Relative ease of User access to the OEDSF supplied element concerning 
transportation, schedule conflicts and/or element sharing constraints 


- INITIAL 

• HARDWARE - Design, Fab and Production of required OEDSF hardware 
elements beyond flight req'ts. 

a SOFTWARE - Development, test and certification of required software beyond 
flight unit needs. 

- CONTINUING 

e MAINTENANCE - Costs incurred by upkeep, repair, calibration and test equip- 
ment required at User’s sites. 


RECONFIGURATION 


SUPPORT 


- Costs incurred for hardware/software modifications per 
user's needs 

- Costs incurred by the OEDSF Program to support OEDSF 
elements through Logistics, operations, support servicing, 
and training 


RESULTS 


The results of comparison of OEDSF alternatives are plotted in Figure 9-12. Highest total scores are 
received by alternatives utilizing characteristics packages for Level V checkout; this results from the 
very low costs (to OEDSF) associated with this approach. Highest benefits are shown by alternatives 
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Table 9-15 OEDSF Integration Concept 


Alternate: Flight OEDSF 


CRITERIA 

LEVEL IV 

LEVEL V 



RATIONALE 

RATING 

RATIONALE 

RATING 


FIDELITY 

Perfect - actual Right system used. 

4 

Same 

4 


SUITABILITY 

Good - some L-IV subassemblies will 

3 

Fair - few individual experiments will re- 

2 

e2 

J— < 


need full OEDSF capability 


quire full OEDSF capability 


USABILITY 

Good - actual flight system interfaces 

3 

Same 

3 



with experiment and CDMS; some 




s 

w 


constraint in using flight unit 




FQ 

RELIABILITY 

Good - actual flight system provides 
proven design and performance 

3 

Same 

3 


ACCESSABIUTY 

Very Poor - limited number of flight 

0 

Very Poor - limited number of flight units 

0 



units makes L-IV support difficult 


makes L-V support impossible 



SUB -TOTAL 


13 


12 


HARDWARE 

Very High Cost - around $700K per 

0 

Same 

0 

i 


copy 




COST 

INITIA 

SOFTWARE 

Low Cost - flight microcode compiler 
used 

3 

Same 

3 

SUB-TOTAL 


3 


3 

w 

MAINTENANCE 

High Cost - high L-IV usage rate of 

1 

Very High Cost - very high L-V usage rate 

0 

D 

o 


flight unit leads to high maintenance 


of flight unit leads to very high maintenance 


& 


costs 


costs 



RECONFIGURING 

Low Co.it - minimum reconfiguration 

3 

Same 

3 

3 

Cj 


required between users 




t 

SUPPORT 

Very High Cost - flight system requires 

0 

Same 

0 

H 

to 


a high degree of logistics, operating 




O 

u 


support, servicing, & training 





SUB -TOTAL 


4 


3 

GRAND TCTAL 
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Table 9-16 OEDSF Integration Concept 


Alternate: Full OEDSF Simulator 


CRITERIA 

LEVEL IV 

1 

LEVEL V 




RATIONALE 

RATING 

RATIONALE 

RATING 



FIDELITY 

Excellent - Speed and accuracy com- 
parable to flight unit 

4 

Same 

4 


BENEFITS 

SUITABILITY 

Good - Some Level TV sub assemblies 
will need full OEDSF capabilities 

3 

Fair - Few individual experiments will re- 
quire full OEDSF capabilities 

2 


USABILITY 

Good - Simulator Design will be com- 
parable to flight unit 

3 

Same 

3 



RELIABILITY 

Good - Simulator emulates proven 
design & performance of flight unit 

3 

Same 

3 



ACC ESSABILITY 

Fair - Limited number of full simu- 
lators may not satisfy the demand for 
Level IV requirements 

2 

Poor - Limited number of full simulators 
can not satisfy the demand of individual 
experiment requirements 

1 



SUB-TOTAL 


15 


13 

1 

C_j 

kJ 

$ 

HARDWARE 

High Cost - Full simulator approaches 
cost of flight unit 

I 

Very High Cost - Many units required to 
support Level V needs 

0 

8 

o 

H 

SOFTWARE 

Low Cost - Flight micro code compiler 
can be used 

3 

Same 

3 



SUB-TOTAL 


4 


3 


xn 

O 

MAINTENANCE 

Med Cost - Design could incorporate 
high maintainability factors to accom- 
modate high usage rate 

2 

Same 

2 


1 

2; 

E 

z 

RECONFIGURING 

Low Cost - Minimum reconfigur^-m 
required between users 

3 

Same 

3 


COST - CC 

SUPPORT 

Med Cost - Full simulator requires 
high degree of logistics and a lesser 
degree of operating support, ser- 
vicing and training 

2 

Same 

2 



SUB -TOTAL 


7 


7 

GRAND TOTAL 

26 


23 
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Table 9-17 OEDSF Integration Concept 


Alternate: Partial OEDSF Simulator 


CRITFFLA 

LEVEL IV 

LEVEL V 



RATIONALE 

RATING 

RATIONALE 

RATING 


FIDELITY 

Good - Speed and accuracy similar to 
flight unit with limited capability 

3 

Same 

3 

tn 

H 

SUITABILITY 

Good - Many level IV sub-assemblies 
will not need Ml OEDSF capabilities 

3 

Good - Most individual experiments will not 
require Ml OErSF capabilities 

3 

t— 1 

Pn 

CaJ 

Id 

USABILITY 

Good - Simulator design comparable 
to the flight unit with limited capability 

3 

Same 

3 

jn 

RELIABILITY 

Good - Simulator emulates proven 
design and performance of flight unit 

3 

Same 

3 


ACCESSABIUTY 

Good - Availability of partial simula- 
tors should satisfy the demand of 
Level IV requirements 

3 

Good - Availability of partial simulators 
should satisfy the demand of individual 
experiments 

3 


SUB -TOTAL 


15 


15 


HARDWARE 

High Cost - Large number of partial 
simulator components may be required 

1 

Same 

1 

COST- 

INITIA] 

SOFTWARE 

Low Cost - Flight microcode compiler 
can he used 

3 

Same 

3 

SUB -TOTAL 


4 


4 

CO 

S3 

o 

I- 1 ‘JNTENANCE 

Med Cost - Design could incorporate 
high maintainability factors to accom- 
modate high usage rate 

2 

Same 

2 

5 

t- 

•z. 

RECONFIGURING 

Low Cost - Adaptable to user con- 
figuration demands 

3 

Same 

3 

COST - CC 

SUPPORT 

Med Cost - Partial simulator re- 
quires a high degree of logistics 
and a lesser degree of operating 
support, servicing and training 

2 

Same 

2 


SUB-TOTAL 


7 


7 

GRAND TOTAL 

26 


26 


trv- 









i * V rJtff*’' 


hik> aSaHMiMi / 


I ■ — - 1 - 1 -- 
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Table 9-18 OEDSF Integration Concept 


Alternate: Software OEDSF Simulator 


CRITERIA 

LEVEL IV 

LEVEL V 



RATIONALE 

RATING 

RATIONALE 

RATING 


FIDELITY 

Fair - Slower than OEDSF with in- 
evitable reduction in accuracy 

2 

Same 

2 


SUITABILITY 

Fair - May r.ot satisfactorily handle 
processing requirements (speed/ 

2 

C jod - Maximizes user’s in-house hardware 

3 

r 1 


accuracy) for Level IV sub-assem- 




W 


blies 




IS 

w 

USABILITY 

Poor - Complex software must be 

I 

Same 

1 

£0 


adapted to a variety of operating 
systems 





RELIABILITY 

Fair - Subject to user operating 
system quirks 

2 

Same 

2 


ACCESSABILITY 

Good - Duplicate software packages 
readily produced and distributed 

3 

Same 

3 

i ^ 

SUB-TOTAL 


10 


11 

H § 

HARDWARE 

Very Low Cost - No hardware re- 

4 

Same 

4 

o ~ 

Ss 

SOFTWARE 

quired from OEDSF program office 

High Cost - Must be customized to 
variety of user equipment 

1 

Same 

1 


SUB-TOTAL 


5 


5 

cn 

D 

MAINTENANCE 

Very Low Cost - Minimal effort 

4 

Same 

4 

O 


after software development 




S 

RECONFIGURING 

Low Cost - Software package 

3 

Same 

3 

s 

o 


handles a variety of check-out 




u 


tasks 




H 

SUPPORT 

Low Cost - Minimum effort after 

3 

Same 

3 

O 

u 


initial development 





SUB-TOTAL 


10 


10 

GRAND TOTAL j 

LiE i 

2C i 






m i i "■ ii'lirii Tim i lllttl l i -ii’iTitiBt" 


lr riirttekflltilYit 
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Table 9-'19, OEDSF Integration Concept 


Alternate: OEDSF Characteristics Package 


CRITERIA 

LEVEL IV 

LEVEL V 



RATIONALE 

RATING 

RATIONALE 

RATING 


FIDELITY 

Poor - Speed and accuracy are dependent 
on resident user’s computer and OEDSF 
character interpretations of user personnel 

1 

Same 

1 


SUITABILITY 

Good - Characteristic package is non- 
user equipment dependent 

3 

Same 

3 

BENEFITS 

USABILITY 

Poor - Requires individual level rv equip- 
ment and software interfaces to be 
established unique to payload element 
configurations. 

1 

Very poor - Requires individual experi- 
menters to interpret characteristics, 
configure equipment for own use and 
extensive coordination for higher level 
integration adaptation. 

0 


RELIABILITY 

Fair - Level IV personnel, interpreta- 
tion of characteristics, on-site equipment 
utiiization/operating system design. 

2 

Poor - Wide varieiy of experimenter 
in-house experience, equipment and 
experimenter requirements. 

1 


ACCESSABIUTY 

Excellent - Maximum utilization of In- 
ll-use resources and equipment 
schedule control. 

4 

Same 

4 


SUB-TOTAL 


11 


9 


HARDWARE 

Very Low Cost - No hardware required 
from OEDSF Program Office (Cost 
burden of User) 

4 

Same 

4 

COS! 

INIT 

SOFTWARE 

Very Low Cost - Common characteristic 
package to all Users (Cost burden of 
User) 

4 

Same 

4 


SUB-TOTAL 


8 


8 

VS 

P 

O 

Z) 

MAINTENANCE 

Very Low Cost - No OEDSF Program 
hardware involved (Cost burden of User) 

4 

Same 

4 

H 

2 

O 

0 

1 

RECONFIGUR- 

ING 

Very Low Cost - Documentation up-dates 
(Hardware and Software costs burden of 
User) 

4 

Same 

4 

COS'l 

SUPPORT 

Low Costs - Minimum consulting level of 
effort oy EODSF program 

3 

Same 

3 

1 

SUB-TOTAL 


11 


11 

GRAND TOTAL 

30 


28 


— — 


r 

k. 
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OEDSF ALTERNATIVE 


Figure 9-12. OEDSF Alternative 

using partial capability hardware simulators for Level V checkout. Total scores for this approach are 
comparable to those for alternatives using software simulations for Level V checkout and are not far below 
those of the characteristic package approach. Low total scores and benefits are shown where fLight hardware 
is utilized. The results show a definite cost preference for the characteristic package approach and a 
benefit preference for hardware simulators, 

CONCLUSIONS AND RECOMMENDATIONS 

Nearly identical high scores are received by alternatives utilizing hardware simulators, software 
simulations, and characteristic packages, whereas alternatives using flight hardware score signifi- 
cantly lower. This is due primarily to limited availability of flight units for Level IV/V integration and 
the high cost of maintaining their flight readiness through extensive ground operations. Hence, the flight 
hardware alternatives are ruled out, and the field is narrowed to ten choices. 

Hardware simulators provide the greatest benefits for integration with the edge to partial capability simu- 
lators due to their flexibility. Characteristics packages offer an inexpensive approach from the standpoint 
of OEDSF but may result in large cost impacts on the users. Software simulations offer an attractive 
cost/benefit compromise. It appears that any of the * emainlng alternatives, with the possible exception 
of full capability hardware simulators for both Level V and Level IV checkout, are viable options. 
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The problem is that user preferences are not well enough understood to malts a clear cut choice between 
them. 

It may well be that a complete spectrum of hardware and software simulations, Including characteristics 
packages, is the answer. This is illustrated in Figure 9-13 where a normal distribution of user integration 
needs is assumed. Some users require a full capability hardware simulator and some can get by with OEDSF 
characteristics packages. The majority of users need partial capability hardware simulators (X%, Y%, or 
Z% of full capability) or can utilize software simulations. The distribution of user requirements {and its 
variation from Level V to Level IV integration) is not presently known and must be determined. 

It is recommended that a more detailed analysis be undertaken to develop firm numbers for user require- 
ments and for simulator costs. Selection of a preferred OEDSF integration support concept should be 
delayed until this analysis is completed. 


PARTIAL CAPABILITY 



OEDSF USERS INTEGRATION NEEDS 


Figure 9-13. OEDSF Users Integration Needs 
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SECTION 10 

RELIABILITY, QUALITY ASSURANCE, AND SAFETY 


The design of the OEDSF has been examined and evaluated with respect to its ability to meet the require- 
ments of shuttle flights in the areas of reliability, quality assurance, and safety (R, QA, & S). 

The OEDSF, as a standard electronics package represents a well known quantity which presents no chal- 
lenge in the areas of R, QA, & S. It ’its well within the envelope of similar systems developed for manned 
spaceflight programs such as MOL, Apollo, Skylab, and Apollo-Soyuz. The unique feature of shuttle flights 
is the seven to fourteen day missions which tend to relax the emphasis on two to three years fault-free re- 
liability and substitute a requirement for maintainability. 

The OEDSF, as a central facility utilized by many experiments, must provide reliable operation: A failure 
of the OEDSF is a mission failure; thus reliability requirements are considerably higher than those on any 
single instrument. Reliability requirements for shuttle experiment equipments have not been totally defined; 
however, standard techniques used in previous automated spacecrafts and manned flight programs are a 
sound baseline subject to modifications tending to reduce these requirements. 

During the study effort for the Onboard Experiment Data Support Facility (OEDSF), General Electric Pro- 
duct Assurance assured through evaluation and participation in the design that appropriate parts, materials, 
materials processes instructions, and controls will be implemented so that the OEDSF processor and power 
supply reliability is achieved and preserved in the translation from the design to operational hardware. 

This will be accomplished through a cost effective step by step control of the design effort, establishing 
proven and controlled Manufacturing and QA practices, reliability predictions, that critical potential fail- 
ure areas are identified using Failure Mode Effect and Criticality Analysis (FMECA), designing a realistic 
test program and necessary hardware protection practices. 

The major elements of this Product Assurance Program consist of design and development methodologies 
used to verify that competent engineering practices are followed, parts and materials selection and applica- 
tions are evaluated for derating factors and dominant failure stresses, evaluation of processing requirements 
for correct process applications, and ability to inspect and test the OEDSF hardware. Potential suppliers 
of procured parts and materials may also be evaluated to determine their past performance and assure 
their ability to meet the OEDSF program requirements. 

Evaluation of the conceptual packaging techniques, parts, proposed materials and process instructions and 
controls were performed. Printed wire circuit boards (PWB) will be processed to existing specifications 
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by a qualified manufacturer such as Bell Industries, Conformal coating on tM PWBs will provide protec- 
tion against environmental conditions such as humidity and cabin atmosphere ana also provide contamina- 
tion control against foreign particles. Material selections are those GE has used on several space programs 
in the past such as Nimbus/Landsat, Skylab, and VQ75. 

Quality and Reliability requirements for parts will be similar to the requirements used by GE in procuring 
parts for Spacelab and tailored to meet the Shuttle requirements. 

Process Specification for soldering, bonding, conformal coating etc. , which are in place can be used for 
this program. 

Handling and Packaging techniques were evaluated and the existing system is deemed adequate to meet the re- 
quirements. Electronic piece parts are carefully c mtr oiled. Special Protective packages are used to seal 
and protect discrete parts until used on the PWB. Electronic shops are equipped with equipment and con- 
trolled environments to prevent damaging effects of electrostatic discharge (Benches grounded, wrist straps 
are provided, plastics with charge carrying properties are not permitted). Fixtures to prevent PWB from 
warpage and maintain flatness will be used during all operations. 

Testing on the PWB and top assembly requirements were also evaluated. The PWBs will be tested before 
and after conformal coating to assume they function properl} prior to installation into the top assembly. 

The Proto/Qualification unit will be subjected to Vibration, Shock, Thermal/Thermal Vacuum and EMC/EMI 
environmental testing with functional tests performed after each environment. Flight hardware will be 
vibration and therraal/tbermal vacuum tested. 

The reliability tasks and objectives of the OEDSF program were to: 

1. Allocate quantitative requirements, predict performance, and eliminate critical effects of failures. 

2. Determine the requirements for control of parts, and materials to be seiected/qualified for use on 
this hardware. 

3. Determine cost effective, and realistic performance and environmental test methods. 

System Safety will be an integral part of the total program effort. Safety will be emphasized and safety con- 
sideration such as personnel hazirds, overloads, energy sources, toxicity of materials, fire suppression , 
outgassing requirements, and emergency procedures will be evaluated through the use of design safety 
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analysis and checklists. Potential safety problems will be defined so they may be assessed and resolved 
to minimize impact to hardware design and cost. 

Specific safety engineering tasks were identified such as hazard resolution procedures, guideline docu- 
ments and checklists, safety requirements for fabrication, handling and test of the hardware, and per- 
sonr'-l procedures. 

The overall purpose of this Product Assurance Program will be to assure the ability of the end product to 
accomplish its mission requirements through cost effective design, fabrication, and validation techniques. 


10 - 3 / 10-4 


SECTION IX 

IMPLEMENTATION PLAN 


Tills section addresses the schedule and Work Breakdown Structure associated with the development of the 
OEDSF. In general it provides a rationale and a roadmap to the development of flight OEDSF hardware. 
Specifically it is the basis of the cost estimate of the OEDSF. 


Two schedules are presented. That shown in Figure 11-1 is patterned after a normal production of flight 
hardware with some modifications to reflect the requirements of Shuttle flight. As indicated in section 10, 
these include relaxed requirements on long term reliability, emphasis on maintainability, and compatibility 
with a manned environment. This schedule envisions the development of a brassboard {or engineering 
model), a protoflite unit; L e., a prototype which, following qualification tests is refurbished to qualify as 
a flight unit, and the production of eight subsequent flight units on two months centers. The schedule is 
matched against scheduled shuttle flights to indicate possible target flights assuming a July 1977 start. 

The schedule shown in Figure 11-2 is based on a phased development of the OEDSF concept. It envisions 
the fabrication of a concept demonstration unit to prove the validity of the conceptual design, a prototype 

1977 1978 1979 1980 



Figure ll-l. Standard Schedule 
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CONCEPTUAL DESIGN 
CONCEPT DEMON ST. UNIT 
PROTOTYPE 
QUAL/FUGHT UNIT 


75 


76 


77 


78 


79 


80 


A™ 
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A. 


DEL 

AZ57 

EVAL 


A. 


DEL 

W 


EVAL 


A 


DEL ^ 


Figure 11-2. Phased Development Schedule 

unit, and a qualification unit, followed by flight production units. This approach is somewhat less efficient 
than the direct development of Figure 11-1 but it provides greater assurance of success because each phase 
follows only upon the successful demonstration of the previous phase. 

Phase I , the conceptual design, is the effort described in this report. 

Phase n is the design, fabrication, and evaluation of a "mini-breadboard’ 1 facility based on the design con- 
cept resulting from Phase I. The breadboard is limited to a rudimentary version with limited software and 
capacity to service two or three medium data rate sensors simultaneously, 

The third phase is the design, fabrication, and evaluation of a full scale prototype OEDSF. This is a mature 
system configured to meet all the requirements of the conceptual design without, however, meeting the re- 
quirements of flight hardware. 

Phase IV is the fabrication of the actual flight unit which is subjected to qualification testing, integrated with 
a complement of payload experiments, and flown to verify its technical and operational performance, 


The development of the Index Generating Program, not shown on these schedules, requires approximately 
three years and should be scheduled to permit its utilization coincident with the assignment of the OEDSF 
to payloads consisting of a full set of sensors . 

The Work Breakdown Structure {WBS) shown in Figure 11-3 is in accord with the development concept shown 
in Figure 11-1. The items in the WBS are defined in the following work package descriptions. 
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EIGHT 

FLIGHT UNITS 































HBPEODUCIBICiirY OP XHi . 

WORK PACKAGE DESCRIPTION FOR COSTING r^TQiNAl PAGE IS POO" 


WORK PACKAGE ; 


1X00 PROGRAM OFFICE 





iWBS i 

TASK 

TO jr 

8N0.,, 

„„ 

FLT UNIT I, 


X110 


1120 


Provide top-level direction and 
integration of required program 
activities . (Limited to applied 
time of program manager and his 
secretary) 

Develop and maintain the top 
level plan for program implemen- 
tation , 


OPS J MPG, 


1130 


Conduct budget planning and con- 
trol activities required for 
program cost control. 

Conduct schedule planning and 
control activities required for 
program schedule control, in- 
house and customer. 

Prepare status reports and 
presentations required for 
program management, in-house 
and customer. 

Prepare contract change proposals 
as appropriate. 

Conduct contract administration 
activities required for program 
implementation. (Limited to 
applied time of contract admini- 
strator and his secretary) . 

Provide finance support required 
for program implementation. 

Provide staff support to Program 
Manager with respect to manu- 
facturing activities. 

Initiate and integrate required 
manufacturing activities. 

Develop and maintain the top 
level Manufacturing Plan. 

Develop and maintain the Malce-or- 
Buy Plan. 

Develop and maintain Handling and 
Storage Plan. 
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WORK PACKAGE: 


1200 DATA MANAGEMENT & DOCUMENTATION 


TASK 


A 
T 

FLT UNIT 


PERFORMANCE OPERATIONS 


TECH 

OPS 


Develop and operate a data manage- 
ment system to provide to the 
customer the data items specified 
in the CDRN. 

Identify data item requirements, 
and initiate activities required 
to provide these data items in 
specified f ormat. (Drawings , user 
manual, acceptance test procedures 
etc. ) . 

Integrate and initiate review and 
approval of each data item, in- 
house and customer, when required. 

Initiate and integrate Tech Pubs 
and Graphic Arts activities to 
provide the data items for sub- 
mittal to the customer. 


Provide Tech Pubs and Graphic Arts 
services as requested by Program 
Office. 





WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


1300 DESIGN REVIEWS 



TASK 


PERFORMANCE OPERATIONS 


Conduct program-level design 
reviews requited by the contract 
as f ollows : 

Preliminary Design Review (PDR) 
Control Design Review (CDR) 
Pre-Environmental Test Review 
Qualification/ Acceptance Review 







WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


2100 TECHNICAL MANAGEMENT 



APP. 

TO 

FLT UNIT 


Provide staff support to Program 
Manager Kith respect. to technical 
matters. 


Initiate and integrate required 
technical activities. 


Prepare and conduct internal 
design reviews. 


PERFORMANCE OPERATIONS ""HI 


II 


-1 



WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


2200 -REQUIREMENT SPECIFICATIONS 


Augment and clarify customer- 
furnished module design and test 
requirement specifications as 
necessary for program implemen- 
tation o 

Develop design and test require- 
ment specifications for each 
in-house and subcontracted com- 
ponent * 

Develop interface requirements 
for GFR components. 


PERFORMANCE OPERATIONS 


iW 


PROGRAM 

| OPS 








WORK -PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE 


2300 PERFORMANCE & TRADE-OFFS ANALYSES 




rVcc’ff’P 


Perform functional performance 
analyses and trade-off studies 
necessary to establish the system 
functional 'configuration. The 
specific analyses and studies to 
'pe .performed include: 

-Test Program Analysis (for* LSI ’s) 
-Timing Analysis 
-I/O Analysis 

-Power Supply /Temperature Check 
-Reliability Analyses 
(e.g. Redundancy FMECA) 
-Performance Analyses ( 

-Requirements Analyses 










WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE s 2400 SYSTEM DESIGN 











WORK PACKAGE DESCRIPTION FOR COSTING 






WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


3300 SAFETY ASSURANCE 




APP. 

TO 

FLT UNIT 


3310 I Develop aod maintain a Safety Pla 







WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


3400 PARTS, MATERIALS & PROCESSES 


TASK 


APP. 

TO 

FLT UNIT 


PERFORMANCE OPERATIONS 


Develop and maintain a parts,' 
materials and processes plan. 
Direct and integrate required 
Parts Program activities. 

Establish and maintain lists of 
pares authorized for progran use, 
including standard and aon'-stan- 
dard parts . 

Establish derating factors , as 
appropriate . 

Prepared controlled procurement 
specifications for all parts 
authorized for use in flight 
hardware . 

Conduct all activities necessary 
to obtain qualification for each 
non-qualif ied part authorized 
for use in flight hardware. 


i 


onduct part inspection, screening 
and burn-in activities, as require 
y the approved Parts & material 
lan . 


Establish procedures for non- 
standard part control. 


onduct activities necessary for 
on-standard part control, in 
ccordance with approved proced- 








WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 35 00 CONFIGURATION MANAGEMENT 



WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


3600 MAINTAINABILITY 








WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4110 ROW PROGRAM CONTROLLERS 


Lbs 


AFP. I 

TASK 

TO F 

jNO.: ■ n ’ 


FLT UNIT l 


■111 


4112 


[DESIGN & DEVELOPMENT 
•Peirform functional performance 
[analyses and trade-off studies 
[to establish the component 
[functional configuration, 

[-Conduct breadboard evaluation 
[necessary to establish functional 
configuration. 

-Conduct design activities 
necessary to establish the com- 
ponent mechanical-thermal con- 
figuration. 

-Conduct manufacturing planning 
for protoflight model and for 
two (2) ground models. 

-Conduct quality control planning 
[for protoflight model and for 
two(2) ground models. 

-Conduct necessary process develop- 
[ment and establish process control^ 

i 

I -Develop test plans and procedures, 
for component test. 

-Prepare drawings and specifica- 
Itions for production of proto- 
| flight hardware. 

FABRICATION & TEST 

-Fabricate protoflight component 

| -Conduct component test of proto- 
flight component- in accordance 
j*with test plans and procedures 
previously developed. 

-Prepare required test documenta- 
tion. 

1 * 

I 

-Perform handling and storage 
activities in accordance with the 
Handling and Storage Plan. 
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WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4120 MAIN PROGRAM 



PERFORMANCE OPERATIONS'^ 


14122 


DESIGN & DEVELOPMENT 
-Perform functional performance 
analyses and trade-off studies 
to establish the component 
functional configuration. 

-Conduct breadboard evaluation 
necessary to establish functional 
configuration, 

-Conduct design activities 
necessary to establish the com- 
ponent mechanical/ thermal con- 
figuration. 


-Conduct manufacturing planning 
for brassboard and protoflight 
models . 

-Conduct necessary process devel- 
opment and establish process 
controls . 

-Develop test plans and pro- 
cedures for component test - 
| acceptance and qualification. 

-Prepare drawings and specifica- 
tions for production of proto- 
flight hardware. 

FABRICATION & TEST 

-Produce protoflight component 

-Provide necessary tools, 

| and fixture 

| -Conduct component test of proto- 
flight component- in accordance 
with test plans and procedures 
previously developed. 

-Prepare required test documen- 
tation . 


-22 











WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


140 DATA BASE CONTROLLER 



PERFORMANCE OPERATIONS 


DESIGN & DEVELOPMENT 
-Perform functional performance 
analysis and trade-off studies 
to establish the component 
functional configuration. 

-Conduct “breadboard evaluation 
necessary to establish functional 
configuration. 

-Conduct design activities 
necessary to establish the 
component mechanical/ thermal 
configuration. 

i 

Conduct manufacturing planning 
for protofligl t model and for 
two(2) ground models. 

Conduct quality control planning 
for protoflight model and for 
two (2) ground models. 

Conduct necessary process 
development and establish 
process controls. 

Develop test plans and pro- 
cedures for component test. 

Prepare drawings and specifica- 
tions for production of proto- 
flight hardware. 

FABRICATION & TEST 

Fabricate protoflight; component 

Conduct component test of 
protoflight component in accordance 

ith test plans and procedures 
previously developed. 

Prepare required test documenta- 


Perform handling and storage 
activities in accordance with 
fchf. Handling and Storage Plan. 


p^RODUCEBiLrnr of the 

'IIIGINAL PAGE IS POOP 







WORK PACKAGE : 


WORK PACKAGE DESCRIPTION FOR COSTING 
4150 SPECIAL TEST EQUIPMENT 










WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 4210 NETWORK 



DESIGN & DEVELOPMENT 
-Perform functional performance 
analysis and trade-off studies to 
establish the component functiona 
conf igurafc'ion . 

-Conduct breadboard evaluation 
necessary to establish functional 
configuration. 

-Conduct design activities nec- 
essary to establish the component 
mechanical/ thermal conf igurat i on . 

-Conduct manufacturing planning 
for protoflight model and ^or 
two (2) ground models, 

-Conduct quality control planning 
for protoflight model and for two 
(2) ground models, 

-Conduct necessary process develop 
ment and establish process control 

-Develop test plans and procedures 
for component test. 

-Prepare drawings and specifica- 
tions for production of protofligh 
hardware . 

FABRICATION & TEST 

-Fabricate protoflight component 

-Conduct component test of proto- 
flight component in accordance 
with test plans -and procedures 
previously developed. 

-Prepare required test documenta- 
tion . 

-Performance handling and storage 
activities in accordance with 
the Handling and Storage Plan. 


PERFORMANCE OPERATIONS 


PROGRAM! TECH 
nwiru 5 OPS 






WORK PACKAGE DESCRIPTION FOR GOST ING 


WORK PACKAGE: 


4220 MATRIX 



[ 

nsrn 

WBS 

TASK 

f fpn | 

HO. ! 

f ■ - 

[FLT UNIT 



4222 


PERFORMANCE OPERATIONS 


DESIGN & DEVELOPMENT 


-Perform functional performance 
analysis and trade-off studies to 
establish 'the component functiona 
configuration. 


-Conduct design activities nec- 
essary to establish the component 
mechanical /thermal configuration . 


-Conduct manufacturing planning 
for protoflight model and for two 
(2) ground models. 


-Conduct quality control planning 
for protoflight model and for two 
(2) ground models. 


-Conduct necessary process develop, 
ment and establish process contro 


-Develop test plans and procedures 
for component test. 


-Prepare drawings and specifica- 
tions for production of protofligh] 
hardware . 


FABRICATION & TEST- 

-Fabricate protoflight component 


-Conduct component tes-t of proto- 
flight component in accordance 
with test plans and p-rocedures 
previously developed. 


-Prepare required test documenta- 
t ion . 


-Perform handling and storage 
activities in accordance with the 
Handling and Storage Plan. 



11-27 


WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4230 SPECIAL TEST EQUIPMENT 



WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4310 CACHE MEMORIES 


r raBr "“H 

m . 111111,11 " " w " , ™ ■ -V 1 ' 

Hsr~i 

WBS 

TASK 

i TO \ 

INO. 


jFLT UNIT f 


4311 I DESIGN & DEVELOPMENT 


PERFORMANCE OP ERATIONS 
OPS ? MFG.f.OA. * 


4312 


-Perform functional performance I 
analysis and trade-off studies to a 
establish 'the component functional 
configuration, 

"Conduct breadboard evaluation 
necessary to establish functional 
configuration,. 1 

-Conduct design activities nee- I 
essary to establish the component 1 
mechanical/ thermal configuration, I 

-Conduct manufacturing planning | 
for protoflight model and for two a 
(2) ground models. | 

-Conduct necessary process develop! 
ment and establish process control! 

-Develop test plans and procedures 
for component test. | 

-Prepare drawings and specifica- 
tions for production of proto- 
flight hardware. 

FABRICATION & TEST 

-Fabricate protoflight component 

-Conduct component tes-t of proto- 
flight component in accordance 
with test plans and p-rocedures 
previously developed. 

-Prepare required test documenta- 
tion. 

i 

-Perform handling and storage 
activities in accordance with the 
Handling and Storage Plan. 


WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4320 LIBRARY 


TASK 


DESIGN & DEVELOPMENT 

-Perform functional performance 
analysis and trade-off studies to 
establish the component function- 
al configuration. 

-Conduct breadboard evaluation 
necessary to establish functional 
configuration . 

-Conduct design activities 
necessary to establish the com- 
ponent mechanical / thermal config- 
uration. 

j 

-Conduct manufacturing planning 
for protoflight model and for two 
(2) ground models. 

-Conduct quality control planning 
for protoflight model and for two 
(2) ground models. 

-Conduct necessary process develop 
ment and establish process control 

-Develop test plans and procedures 
for component test. 

-Prepare drawings and specifica- 
tions for iroduction of proto- 
flight hardware. 

FABRICATION & TEST 

-Fabricate protoflight component 

-Conduct component test of proto- 
flight component in accordance 
with test plans and procedures 
previously developed. 

-Prepare required test documenta- 
tion. . 

-Perform handling and storage 
activities in accordance with the 
Handling and Storage Plan. 


PERFORMANCE OPERATIONS 


FLT UNIT 


PROGRAM TECH 
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WOrK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE; 


4330 SPECIAL TEST EQUIPMENT 



WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 4410 MODULE A 


FLT UNIT 


DESIGN & DEVELOPMENT 

-Perform functional performance 
analysis and trade-off studies 
to establish the component 
functional configuration. 

-Conduct breadboard evaluation 
necessary to establish fuhctioiial 
configuration. 

-Conduct design activities 
necessary to establish the com- 
ponent me chanic al/ thermal con- 
figuration . 

I 

-Conduct manufacturing planning 
for protoflight model and for two 
(2) ground models. 

-Conduct necessary process develo] 
meat and establish process control 

-Develop test plans and procedure 
for component test. 

-Prepare drawings and specifica- 
tions for production of proto- 
flight hardware. 

FABRICATION & TEST 

-Fabricate protoflight component 

-Conduct component test of proto- 
flight component in accordance 
with test plans and procedures 
previously developed. 

-Prepare required test documenta- 
tion. 


PERFORMANCE OPERATIONS 


6 OPS 


-Perform handling and storage 
activities in accordance with the 
Handling and Storage Plan. 
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WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE : 


4420 MODULE T 


4422 


PERFORMANCE OPERATIONS 


APP. 

d P tt°ttntt jHiOGRAMl TECH) 

|I>L1 UN 11 In-Dt'-ro'c- t OPS MFG 


4421 I DESIGN & DEVELOPMENT 


-Perform functional performance 
analysis and trade-off studies 
to establish the^xomponent . 
functional conf iguraion . 


-Conduct breadboard evaluation 
necessary to establish function- 
al configuration. 


-Conduct design activities 
necessary to establish the com- 


ponent mechanical/thermal con- 
figuration. 


-Conduct manufacturing planning 
for protoflight model and for twc| 
(2) ground models. 


-Conduct quality control planning 
for protoflight model and for fcwc 
(2) ground models. 


-Conduct necessary process devel- 
opment and establish process 
controls . 


-Develop test plans and procedure^ 
for component test. 


-Prepare drawings and specifica- 
tions for production of proto- 
flight hardware. 


FABRICATION & TEST 
-Fabricate protoflight component 


-Conduct component test of proto- 
flight component in accordance 
with test plans and procedures 
previously developed. 


-Prepare required test documenta- 
tion . 


-Preform handling and storage 
activities in accordance with t hej 
Handling and Storage Plan. 
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WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4430 MODULE 


TASK 


PERFORMANCE OPERATIONS 


TECH 

OPS 


DESIGN & DEVELOPMENT 

-Perforin functional performance 
analysis and trade-off studies t 
establish the component function 
al configuration. 

-Conduct breadboard evaluation 
necessary to establish function- 
al configuration. 

-Conduct design activities nec- 
essary to establish the compon- 
ent mechanical /thermal, config- 
uration . 

-Conduct manufacturing planning 
for protoflight model and for tw 
(2) ground models. 

-Conduct quality control p'lannJnj 
for protoflight model and for twt 
(2) ground models. 


-Conduct necessary process devel- 
opment and establish process 
controls. . 


-Develop test plans and procedure 
for component test. 

-Prepare drawings and specifica- 
tions for production of proto- 
flight hardware. 

FABRICATION & TEST 

-Fabricate .protoflight component 

-Conduct component test of proto- 
flight component in accordance 
with test plans and procedures 
previously developed. 

-Prepare required test documenta- 
tion. 


-Perform handling and storage 
activities in accordance with the 
Handling and Storage Plan. 




WORK PACKAGE DESCRIPTION TOR COSTING 








WORK PACKAGE DESCRIPTION FOR COST ING 


WORK PACKAGE : ,4510 INPUT INTERFACE REGISTER 



TASK 


DESIGN & DEVELOPMENT 


-Perform functional performance 
analysis and trade-off studies to 
e s t ab lirS- h - -fc - h - c — e cmp e-a-e-rrt — g - un - e - t ^i o na 
configuration . 

-Conduct breadboard evaluation 
necessary to establish functional 
configuration . 

-Conduct design activities nec- 
essary to establish the component 
mechanical /thermal configuration. 

-Conduct manufacturing planning 
for protoflight model and for two 
(2) ground models. 

-Conduct necessary process 
development and establish process 
controls . 

-Develop test plans and procedure 
for component test. 

-Prepare ^ixawjLngs and specifica- 
tions for production of profcoflig 
hardware . 


(4512 1 FABRICATION & TEST 

-Fabricate protoflight component 


-Co 

nduct 

component test 

of proto- 

fli 

ght c 

omponent in accordance 

wit 

h t es 

t plans and pro 

cedures 

pre 

vious 

ly developed. 
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WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE : 


4520 OUTPUT INTERFACE REGISTER 


45 21 I DESIGN £t DEVELOPMENT 


APP* I 
?LT°UNIT 


PERFORMANCE OPERATIONS 

TOCTTT 


-Perform functional performance | 
analysis and trade-off studies to | 
establish- the comp.onen.fc . f un ctiona3i 
configuration. g 

-Conduct breadboard evaluation | 
necessary to establish functional i 
(configuration. g 

-Conduct design activities nec- | 
essary to establish the component | 
mechanical/thermal conf iguratinn. | 

-Conduct manufacturing planning | 
for protoflight model and for two ] 
(2) ground models, { 

-Conduct quality control planning S 
for protoflight model and for two I 
(2) ground models. | 

-Conduct necessary process develop- 
ment and establish process controls, 

-Develop test plans and procedures 
for component test. f 

-Prepare drawings: and specifica- 
tions for production of proto- 
flight hardware. 


4522 I FABRICATION 


TEST 


-Fabricate protoflight component 

-Conduct component test of proto- 
flight component in accordance 
with test plans and procedures 
previously developed. 

-Prepare required test documenta- 
tion. 

-Perform handling and storage 
activities in accordance with 
the Handling and Storage Plan. 


11-37 


WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4530 FIFO 


TASK 


WamMMB maMa»MaB»CHtoOT«M«BaBttaMiEnaEOBBmg™ 

DESIGN & DEVELOPMENT 

-Perforin functional performance 
analysis and trade-off studies to 
establish the component function- 
al configuration. 

-Conduct breadboard evaluation 
necessary to establish functional 
configuration. 

-Conduct design activities nec- 
essary to establish the component 
mechanical/ thermal configuration . 

-Conduct manufacturing planning 
for protoflight model and for two 
(2) ground models. 

-Conduct quality control planning 
fcr protoflight model and for two 
(2) ground models. 

-Conduct necessary process develop- 
ment and establish process con- 
trols . 

-Develop test plans and procedure! 
for component test. 

-Prepare drawings and specifica- 
tions fhr production of proto- 
flight hardware. 

FABRICATION & TEST 

-Fabricate protoflight component 

-Conduct component test of proto- 
flight component in accordance 
with test plans and procedures 
previously developed. 

-Prepare required test documenta- 
tion . 

-Perform handling and storage 
activities in accordance with 
the Handling and Storage Plan. 
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PERFORMANCE OPERATIONS 
IPlOGRAMf 
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WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


4610 STRUCTURE 





design update 


-Modify drawings and specifica- 
tions, manuf acturing/quallty 
control planning, and test plans/ 
procedures to incorporate changes 
necessitated by engineering 
model tests. 


FABRICATION 


-Produce protoflight model 


PERFORMANCE OPERATIONS 


■ 








WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


5100 ASSEMBLY 
























WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


5400 FLIGHT ACCEPTANCE TEST . 


TASK 


5410 


Prepare flight acceptance test 
plans and procedure: 


11-44 


Conduct fli ght accep tance tes_fc 
operations on the refurbished 
protoflight Matrix Processor. 


Evaluate test data and prepare 
acceptance test documentation. 


Pack, box and ship 


REPRODUCIBILITY OF THi 

iTUGINAL page is poor 


PERFORMANCE OPERATIONS 
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PROGRAM! TECH 
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WORK PACKAGE DESCRIPTION FOR COSTING 



WORK PACKAGE: 6100 MATRIX PROCESSOR BRASSBOARD 



1. Repeat Work Packages 4100, 
4200, 4300, 4400 and 4500, ex- 
cept use commercial parts. 


2. Repe at W or k -B -a-g-ka-ge- 4610— to- — 
fit brassboard packaging concept. 

3. Perform assembly and accept- 
ance test in accordance with 
work packages 5100. As modified 
for brassboard concept. 






! 
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WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


7100 ELECTRICAL GSE 





WORK PACKAGE DESCRIPTION’ FOR COSTING 


WORK PACKAGE: 


7200 MECHANICAL GSE 





PERFORMANCE OPERATION’S 


TECH 

ops 


7210 


DESIGN & DEVELOPMENT 


-Develop design and performance 
requirements for Mechanical GSE 


-Perform design activities to 
produce production drawings and 
specification. 


7220 


FABRICATION & TEST 


-Produce Mechanical GSE equipment 
-Conduct test on equipment 


-Pack, box and ship 
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WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 7 300 SOFTWARE 




WORK PACKAGE DESCRIPTION FOR COSTING 


WORK PACKAGE: 


8100 SOFTWARE 
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WORK PACKAGE DESCRIPTION FOR COSTING 


i 

WORK PACKAGE : 8200 COMPUTER SYSTEM 



Major Technologies 
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Two major technologies have emerged in semi-conductors during the last decade 
i.e. bipolar and metal -oxide -semiconductor (MOS) . The most popular and time tested 
bipolar technology is transistor -transistor logic (TTL) including low power 
schottky and schottky. The most popular MOS technology is SF-Channel MOS with 
P»channel MOS maintaining the time proven position. This technology forecast 


does not expound on the differences and characteristics of each technology but 


presents each process since the developments are equally distributed. 


The major technologies and 
their projected performance 
characteristics over a 
decade is shown in Table A.l 
Table C.l indicates that the 
major technologies during 
the next decade will be low 
power schottky and integrated 
injection logic (I L) for 
bipolar technology and CMOS/ 


Technology 

Speed Power 
Product (pJ) 

Gate 

propagation 
Delay (nsec) 

'Gate 
Density 
(gates/mm 2 ) 

Date of 
initial 
Production 

P-channei 
metal gate 

450 

80 

50 

1966 

P-channel 

Si-gate 

145 

30 

80 

1969 

Schottky 

bipolar 

60 

6 

25 

1969 

N-channel 

Si-gate 

(High voltage) 

45 

15 

95 

1972 

N-channel 

Si-gate 

depletion load 

38 

12 

110 

1974 

Si-gate CMOS 

0,5 

10 

45 

1973 

l z L 

1 

50 

40 

1975 

CMOS/SOS 

0.2 

3 

100 

1977(?) 


SOS for the metal oxide semi- 
conductor technology. These 


MAJOR TECHNOLOGY CHARACTERISTICS 
TABLE A.l 


technologies fabricated on a standard 0.25 inch by 0.25 inch wafer equate to 


159 gates at 1.0 milliwatts for metal oxide semi conductor . Bipolar technology 


will be characterized by 127 gates at 2.54 milliwatts. These equate to a factor 
of 0.5 reduction in average power and a factor of 10 increase in speed during the 
1980-1985 timeframe. The operational characteristics of existing technologies 


are shown in Table A. 2, The projected characteristics are shown in Table A. 3. 


n 

1 ; 


A-l 


Parimittr 

Standard 

TIL 

low-poww 

m 

1741] 

PTl 

towjioww 

Sthnllky 

' l 

CMOS 
(ErV wppty] 

C-MOS 
[IHV toppiy) 

Propagation tfeliy 

10 m 

33m 

30 m 

5-10 m 

35 ns 

25 m 

frirpHiiey 

35 MHz 

3 MHz 

5 MHz 

40-80 MHz 

5 MHz 

ID MHz 

QuiamrUpovyj' 

IDmW 

ImW 

8.5 mW 

2mW 

lOitW 

10 nW 

Koln imnSIinity 

IV 

IV 

IV 

0.0 V 

2 V 

4 V 

Fanout 

! 

10 

10 

6 

20 

£0* 

50° j 
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general operational characteristics 

TABLE A. 2 


The projected values are not a straightforward application of the anticipated 
gains . Regression analysis reveals that each technology possesses an upper 
limit which when applied to the existing parameters yields the anticipated para- 
meters. The projection indicates that the operational frequency and power are 
well suited for flight systems during the desired timeframe. Further, the 
anticipated bipolar technology of integrated injection logic is not shown 
since its parameters are still in development stages. Manufacturer’s are 
hypothesizing that this technology during the next five years will surpass the 
standard' transistor and schottky logic families. 
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PROJECTED OPERATIONAL CHARACTERISTICS 


TABLE A. 3 


The final aspect of the technologies is the packaging. Higher gate densities 
result in more powerful functions capable of being fabricated on a small area 
of silicon. Increased functionality requires increased pin counts if speed is to 
be maintained. This is evidenced by the current trends in moving from 14 pin to 
24 pin packages. Figure A.l. Pin counts are increasing accompanied by increases in pack- 
aging yields, component assembly yields, test capabilities, and repair ability. Figure A.l 
indicates that packaging pin counts will not increase at a rapid rate so that no 
ramifications are anticipated for printed circuit board designs as well as board 
and component qualification processes . 

These technology developments 
are based on the increased 
demands for microprocessors 
and large high speed semi- 
conductor memories. Each of 
these areas are briefly 
discussed below due to their 
importance in simiconductor 
technology development. 


Microprocessor Trends 

The microprocessor has created the major demand on technology advancement during 
the last 5 years. Each new development results in a more power processor capable 
of replacing large scale and mini -computers with tremendous cost savings as 
shown in Figure A. 2. Excluding general electronic data processing areas such 
as health insurance fields, micro -computers will be employed more frequently 



PIN COUNT TRENDS 
FIGURE A.1 


A-3 


100M' 



MIPS = MILLION INSTRUCTIONS PER SECOND 

PROCESSOR TRENDS 
FIGURE A.2 

with cost savings being several orders of magnitude. 


The microprocessor trends shown in 
Figure A. 3 indicate that the figure 
of merit for the processors are linearly 
improving. The processor figure of merit 
is the product of the chip area, dissipation 
and instruction cycle time divided by the 
product of word length and number of 
instructions . 



PROCESSOR FIGURE OF MERITS 
FIGURE A .3 


In addition, the cost per gate is decreasing 
linearly as shown in Figure A. 4. The signifi- 
cant cost reductions are being achieved through 
high -volume and the increases in technology 
sophistication. The basic gate structure for 
integrated injection logic is composed of two 
transistors -one parasitic and one diffused so 
that technology is rapidly approaching the theoretical 
limit of one transistor 



PROCESSOR COST/GATE TRENDS 
FIGURE A . 4 
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per logic gate. This trend yields lower cost and increased functional power 


per single silicon chip. t 


■ 

gggg 



Table A. 4 shows the basic size of available 

.. .Type .No.-' 

CPU Bits. 
(bTVitrct.titi 

Address 

Capacity 

Comments* .' 
Developing Manufacturer** 

microprocessors in 1975. It must be remain- 

p-MOS 





LP 8000 


a 

2-1t 

General Instruments 

bered that less than 5 years ago, only one 

*1004 


4 

4-k 

Intel 


4040 


4 

4-k 

Intel 

or two processors with crude architectures 

8003-1 


8 

16-k 

Intel 


506S 


8 

32-k 

Mosiek 

were available. Today, there are over 30 

GPC/P 


4 

100 

BS, MP, National 

such devices with support components and 

IMP-4 


4 

4-k . 

MP, MC, National * 

IMP'S 


8 

64-k 

MP. MC, National 

software to rapidly realize a sophisticated 

IMP-1E 

PACE 


16 

1G 

64-k 

64-k 

MP. MC, National 
MP. MC. National 

one or two board general or special purpose 

PPS-4 


4 

4-k 

SV, Rockwell 


PPS-8 


B 

16 k 

SV- Rockwell 

computer. Trends indicate that during the 

PPS-4/2 


4 

128 

CC, SV. Rockwell 


TM51000 


4 

8 k 

SV. MP, Texas Instruments 

1980 timeframe this list will at least 

SC/MP 


8 

G4-k 

CC. SV. National 

triple with the standard processor being a 

n-MOS 





EA 9002 


8 

64-k 

SV, Electronic Arrays 

16 bit fixed instruction GPU and a 4 bit micro- 

P-8 


a 

64-k 

CC. Fairchild 


CP- 1600 


IB 

fri k 

MP, Gene: Instruments 

programmable slice. The anticipated speed of 

808 D 


8 

FVk 

Intel 


6501 


8 

64-k 

SV, MOS TerhitDloriv 

these machines is a register to register 

M6800 


3 

64 k 

SV, Motorola 

addition time of 125 namoseconds. 

CMP-8 


a 

64-k 
32 k 

National 
SV, Signctici 

2650 


& 


TLCS-12 


17 

4-k 

MP, TothtL-j 


MOP- 1600 


IG 

G4k 

MP, MC. Western Digital 


PFL1GA 


16 

G4k 

MC, Panalacom 

Pro- 

C-MOS 




SV, RCA 


COSMAC 


B 

r»4'k 

jected cycle times limit these devices from 

6100 


12 

4-k 

SV. CC. Intersil 

being universal solutions. Finally, it must 

Bipolar 





3002 


2 

512 

BS. SV, MP, Intel 

be remembered that these devices require 

RP16 

6701 


4 

64 k 
64 k 

BS, ECL, MC. SV. Raytheon 
BS, SV, MP, Monolithic Memcmoi 


4 

additional components so that a microcomputer 

SBP040D 


4 

64 k 

l ? L, CC. BS, SV. MP. T«*as Imtiumenu 

1601 


4 

37 k 

BS. MP. Transition 

is not just the micropordessor or a single 

2901 


4 

64 k 

BS. MP, Advanced Micro Devices 


laaoo 


4 

64 k 

BS. MP, CC. ECL. Motorola 

chip. At the present time only Texas Instru- 

9400 


4 

64 k 

BS, MC. MP, SV, Fanctl ild 

ments manufactures a single chip computer. 

■notes 

as 

MP 

B'i diet* • 

Mictapmyramoble 

( ? L - In tnjr a[i*d inaction Iqijic 
SV Sliiylt 1 vnltOljn 



ECl 

Emnlei coupled logic MC ■ Mulu chip c(tu 






CC - CJpek on chip 


j St'CtJfid IGtJfCrt not hskd 
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TABLE A, 4 
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This computer possesses a fixed program so that it is oriented for high volume 


applications and requires careful program development. The demands on microprocessors 


and microcomputers require a concentrated effort on semi-conductor memory and 


Memory Trends 


Memories have emerged as a technology metric for density, yield, and reliability 


Several years ago, the major effort was to develop the 1024 bit random access 


static memory capable of operating at cycle times under 200 nanoseconds. Today 


the 65,536 bit random access dynamic memory with a cycle time of 180 nanoseconds is 


The memories exhibit an increased figure of merit as shown in Figure A. 6. The 


figure of merit is the product of 


access time divided by the number 


DISKS 

('0.0015 «/ BIT) 


ELECTRON BEAM 
(' 0.05 «/ BIT] 


A. 6, the characteristics of the 


static random access memory are 


rapidly converging on the charac 


BUBBLES 
('0.05 (!/ BIT) 


teristics of the dynamic random 


access memory 


CORE ('0.5 $ / BIT) 


technology will yield high per 


BIPOLAR ('1.5*/ BIT) 


formance high density static random 
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shown in Figure A. 7 


CURREOT MEMORY CHARACTERISTICS 


FIGURE A. 5 


REPRODUCIBILITY OF Till 
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CESS-MEMORY PERFORMANCE 


^ 160 , 
ACCESS TIME,(nt> 


MEMORY COST TR'TTDS 


MEMORY FIGURE OF MERIT 
FIGURE A. 6 


FIGURE A. 7 


Finally, random access memory performance characteristics for various technol 


ogies are shown in Figure A. 8 


(1977 DENSITY) 


(19/8 

SPEED) 


STATIC l*L 


(1975 DENSITY) 


STATIC C MOS ON-SAPPHIRE 


(1978 

SPEED) 


STATIC BULK CMOS 


STATIC TTL 
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FIGURE A. 8 


he 1980-1985 technologies will yield 25 to' 50 


nanosecond 4-16 kilobit memories which are required for high speed signal processing 
A 16K x 16 bit memory in an operational mode will require approximately 13.1 watts. 


iddition, many systems require a large off-line storage. The magnetic tape 









units provide the maximum capacity but are slow and unreliable. Current 


research efforts focus on disc file storage. The projected capacities for this 
storage media are shown in Table A. 5 which indicates that the anticipated 


storage requirements for shuttle era will be met with 2 or 3 devices. 
In summary, the over -all 


performance range of LSI 

Year 

Linear Density 

Track Density 

Storage Density 


(bits/in.) 

(traces/in.) 

(bits/ in.*) 

technologies is shown in 

1960 

200 

40 

3000 


1965 

2200 

100 

220,000 

Figure A, 9. From this 

1970 

• 

4000 

200 

800,000 

chart, the rapid advances 
in simitonductor development 

• 

• 

1985 

160,000 

2000 

320 x 1 0“ 


are indicated by research 


and development in schottky integrated injection logic while standard integrated 


injection logic is still in the initial production stages. 
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The number of components (e.g. transistors, resistors, diodes) per integrated 
circuit chip shown in Figure A, 10 has been increasing exponentially. The physical 
limitation of the number of 
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a 
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o 
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components that can be fabricated 
in a given area with an 
acceptable yield is dependent 
on the optical diffraction limit. 

This limit assumes 0.1 mil 
minimum features over a 2 in. 
diameter wafer and has been 
achieved under laboratory conditions. 
Moreover, smaller dimensions are 
capable of being achieved using 
emerging electron beam and X-ray 
lithographic techniques. Technology 
trends indicate more power, higher 
reliability, and lower cost com- 
ponents accounting for the major 
shift back to hardware centered systems. 
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Thesis : 

Many functions required in information processing are characterised by or 
based on polynomials. Further, trigonometric, exponential, and logarithmic 
functions are polynomial approximations of an argument. In addition, each 
process required by the boundary sensors are capable of polynomial solutions. 
Increased interest in numerical analysis has established the importance of the 
polynomial and the ability to implement a polynomial. Since increased 
information processing such as information processing, is anticipated for the 
Space Shuttle Era, the polynomial must be evaluated as a viable solution, It 
will be shown that the uniqueness of the polynomial based solution permits the 
combination of several discrete processes reducing both the number of processing 
steps and machine complexity including time required. In investigating the 
applicability of this approach, the general algorithm will be developed and 
consequently , implemented in both hardware and software with the software 
implementation focusing on standard micro-computer. 
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Polynomial Analysis ; 

From basic mathematics, a general polynomial may be expressed as 
H N-l 

eq- (1) P (X) = a * Y (X) 

n=0 n 

where N ~ the order of the resultant polynomial 

th 

% “ the coefficient of the n term 

th 

and 3 ^ ” the value of the argument for the n term 

In particular, a Maclaurian series polynomial with Lagrange coefficients may be 
expressed as 


N N-_l 

eq. (2) P (X) - ;§£ a n *X 

n-0 


where 


n 


y = x 


Cl 




The resultant polynomial in equation 2 is solely dependent on the derivation 
of its coefficients for its resultant characteristics. For example, one set 
of coefficients when applied will yield a particular trigonometric function while 
another set of coefficients will yield a logarithmic function. Some typical 
functions and processes based on ploynomials are listed in Table C-l. 

If equation 2 is expanded about the argument, the polynomial may be 
written as 

eq. (3) pWjtf] - a Q + a / + + 1 

where a^ =r a signed number 
x n — a signed number 

However, this polynomial may be solved for its roots by several methods - 
typically Newton’s Method, resulting in a set first order polynomials 
expressed as 

eq. (4) P N \x) = (c 0 *X +b 0 )* [c l *X+b l )* * r l C A/-/* J( ' + b N-l ) 

where c. /b — the n ^root of the polynomial 

n n 

This form of the polynomial provides the basis for the implementation. Initially, 
assume that the coefficients are known a priori and are not a function of the 
argument but rather a function of the process to be performed. Based on 
equation 4, the general polynomial relationships may be determined. 
lemma 1 ; 

The characteristic polynomial in equation 4 may be expressed as a set 
of first order polynomials or a set of lower order polynomials by grouping 
adjacent terms. If adjacent pairs are grouped, then 

eq. (5) - [ ( Cq*X 4 b Q Ja? ( C,*X + b f j] * « , # 

[ ( C N ~ 2 4 * b N~2 )* ( C N-I* X '^ b H-l 1 J 

so that 
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eq 


• (6) P N \x\ - [c 0 *c / ^fX 2 + f<^>* bp)** 4- b Q *£>/] 

[ C W-2*W*M C ,V-2*V/ + c N-l* b N-sh x + V/* b /«?] 

which allows the basic polynomial to be expressed as 


eq. (7) 

P n'\ 

7 2 

L 

J= A n XX 2 - 

where 

A n 


c n* c n+i 


Bn 

— 

c n * *>nt/ H- 

and 

C n 

* — 

b n* b ml 


n 


'n 


J r 


if the roots are grouped by three's, then 
eq. (8) oNl. ] _ 


|a ] _ [[c c *'X + fa 0 )jf j C/ * X + b, )# [c £ *A-+ b £ ) J 4^ 

[ [(yf* + +/L 4 )*(c 5 >-A + t s )]*. . . 

x+ 0 O, )j 




so that 
eq. (9) 


p w (x)- [c 0 * c ,* c 2 i c o* c >* b z + c /* c : 1 

-f [ci%b 0 * b 2 -j- b ; *: b.- -f- c..* b r # b f )# X -f * & , ¥ t ^ j # „ 


• # # * ^ L 

which results in a basic polynomial expressed as 

■+ C n *X - 


eq. 

(10) 

P n 

M = 

A n $ X" 

' + B n * 

where A n 

— 

C /J~l 

C N~2 * 

C N~3 

■+■ 


Bn 

r= 

c A/-3 * 

C N-I * 

b N-2 


c n 

1 — 

C /V-3* 

b N-l * 

b N * 


and 

D n 


b N-t * b N-2 * 

b N~3 



<-N-r w N-2 


77-3 


Consequently, the polynomial expressed in equation 4 may be written as 
eq. (11) P N \x) p£\x m )# P^[x n ^ P 2 [x m ) ^ , a . pfy^X n> ) 


where spline or basis function 

a °d m ~ the order of the spline or grouping factor 

Therefore, the number of splines required to realise an n" order 
polynomial may be expressed as 


fh 
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# 
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ec I* ( 12 > 1 - N / m 

where i is truncated to the next higher integer value. For example, let 
N =21 and m =2 which requires 10 second order s lines and 1 first order 
spline. However, since all splines are of the same order, 11 second order 

splines would be required to realize this polynomial. Figure C- 1 summarizes 

the number of splines required to achieve a resultant polynomial of order N as 
a function of the order of the spline, 

In addition, the number of coefficients required to achieve this order 
are shown for various splines and polynomials in Figure C-2 . Based of these 
two’ figures , the most significant change occurs between a first and second 
order spline with the higher order splines influence appearing for extremely 
high order polynomials. The general characteristics of splines are listed in 
Table C-2 . Based on these parameters, the second order spline was selected as 
being the most advantageous for the typical polynomial orders incurred in information 
processing - usually 14 or less. 
lemma 2; 

The ability to implement a set of splines along classical design paths 
would result in a cumbersome, uneconomical, futile system rather than a simple 
function generator. In addition, unless exponentially increasing data paths were 
maintained, significant errors would be present in the resultant solution. 
Re-iterating equation 11 yields, 

eq. (13) P N x) - pM\x ni ]% pM \ m . U I 

or in more general terms 

eq - (W> p"|xj = g // (* m )*p, N (/'■)* 

where/ — the number of splines required to realize the resultant polynomial 
For i= (^equation 14 yields 




n. 


+p N {x' r ‘i 1=1 c 
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eq. (15) Pq[x] = 

For i = 1 

eq. (16) pH jxj - fx m j& P^fx™] 

so that substitution of equation 15 yields 
eq. (17) pH fxj = P^{x m )* p£j(x J 
For i— 2 

eq. (18) P*(x} = P^(x m J^P^(x m J i¥ .P^(x rn j 

so that substitution of equation 16 yields 
eq. (19) (x] = ^pflx) 

For i = 3 

eq. (20) p"( X j = fA(x m )* ")**"[*'> P^X™) 

so that substitution of equation 18 yields 
eq. (21) P*(*j = P 3 W (x m ]* f^(x] 

th 

therefore for an arbitrary n order polynomial 
eq. (22) p«fx) = P n N fx m j*P n ^(x) 

which is the basic equation that must be implemented. One argument is the 
spline based on the coefficients of the final term and the second 
argument is the resultant polynomial for order N - 1, 

Algorithm : 

Based on the foregoing discussion, the algorithm for realizing a 
a general order polynomial at the proceedural level is straightforward. 
Assume that the a spline of order m is employed and a resultant polynomial 
of order N is desired. Further, assume that the resultant polynomial 
is an initial condition that may be programmed in the feedback loop. 
Employing these assumptions, the following proceedure is required; 

9 Compute the value of the spline for the n term of the polynomial 


C9 


*f*ht 

e Compute the product of the n spline and the resultant polynomial for 
order |n - 1 J 

9 i Save the resultant value and place the truncated value in the 
feedback loop 

3 Determine if the desired order is achieved: 

a, if N/m , repeat the process 

b, if n = N/m , output the resultant value 

This process requires N/m iterations of the basis function employing an 
organization shown in Figure C-3 and a general process flow shown 
in Figure C-4 . Finally, the feasibility of the polynomial solution to 
information processing is dependent on the ability to implement the 
function and the resultant characteristics of the specific design. 

Timing Aspects : 

The periodicity of the argument establishes the requirement to 

J.L 

compute an N r/1 order polynomial with basis functions within a specified 

time. Further, for multi- frequency sensors, this requirement is bounded by 

the upper value of the required bandwidth of operation. Initially, assume 

that a basic order may be computed within one machine cycle of the array 

processor. Let this machine cycle be configured in such a manner that the 

machine periodicity is either that of the argument or determined from an 

independent source such as an oscillator. The periodicity of the array will 

be defined as T c . If the time required to compute a spline and the product of 

of this spline and the resultant polynomial for one order less than the spline 

term is defined as T . The number of iterations that must be achieved during 

r 

one machine cycle is 


CIO 















eq. (23) 


n = Tc /t b 


where n — the iterations truncated to lower interger value 

Consequently 3 if an m order spline is employed, the resultant 
polynomial that may be achieved during one machine cycle is 
eq. (24) M = r>-fcm 


and the number of machine cycles required to achieve the desired order is 


eq. (25) 


X- 


N 

M 


where J — the machine cycles truncated to higher integer. value . 

These constraints must be evaluated during the processing of a specific 
sensor to determine if the required bandwidth is maintained. 

Hardware Implementation : 

The functional block diagram for a hardware implementation is shown 
in Figure C-5 . The organization is centered on a 16-bit argument and a 
second order spline. The spline coefficients are each 16-bits except for 
the bias coefficient which is 32-bits. This organization performs internal 
operations in double precision and provides a double precision value. The 
output value that is re-circuiated via the feedback loop ls truncated to 
16-bits while the full 32-bit result.'- 1 is available at the output as 
two sequential machine words. 

The circuit operates in the following manner: Let each iteration be 
concurrent with the machine state clock so that for 
eq. (26) ^o( n J ^ / p! n+/ ) 

the following condition is achieved 


eq. (27) p"(x) > P^lxj 

During ^ _y > the coefficient table is addressed allowing the required rnsf f icients 
for the n term to be present at the input of the coefficient register prior 
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to the leading edge of L(n} AtTLCn^the argument and the coef ff icents , and 

N , . P P 

/P j(X ) are clocked into the polynomial generator or computational portion 
of the circuit where the resultant polynomial is computed. On each succeeding 
state, the process is repeated until the final or output state is achieved. 
Therefore, the resultant polynomial may be any order in the following range 

eq. (28) Q « P^[x m )>M 

Based on the functional block diagram, the state diagram for this 
function is shown in Figure c-6 with the worst case path indicated. 
Employing the worst case path, the event time for this operation with 
N iterations is 

eq. (29) £ [ p*| x J J = [ n - / ) T( . + '/.-/ } Tp + i>° + f, 

and for a single iteration as 


eq. (30) 


f -4 


= In - / J t c + ^ 

° n= c 


The figure of merit for several iterations is extracted from equation 29 as 

eq. (31) 7 [(£[*)] =[N-,)Tp+^ke n 

and for a single iteration from equation 30 as 

< 32 > 7 [ p n U ) 1 = e n 

L 1 ’ J n= c 

Employing conventional MSI and LSI technologies, this function would 
require approximately $ 5 integrated circuits for the word sizes indicated. 
The coefficient table is Random Access Memory and assuming not more than 
8 iterations per machine cycle would require 512-bits. The organization of 
the table would be three groups of words i.e. 8 x 16, 8 x 16, and 8 x 32 . 

For n iterations, the configuration would be n x 16, n x 16, and n x 32 
for a total of n x 64 bits which is realistic for the polynomial orders 
considered. For example, i : 32 iterations are required, only 2048 bits 
would be required for the table capacity. 
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Software Implementation: 


Based on the subroutines listed in Appendix A, the software 
implementation benchmarked on an 8080A microcomputer is shown in 
Figure C-7 . This microcomputer would require approximately 100 MSI/LSI 
integrated circuits. The execution time for a software implementation 
is 

eq. (33) T = ( 434 +X * 1332.5 ] ty S©C 

and the computer loading is 

eq. (34) L - 44 7 BYTES PLl'S CCEEE !C IEN T TABLE 

The characteristics for each implementation are listed in Table C-3. 
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ONBOARD EXPERIMENT DATA SUPPORT FACILITY 
CONCEPTUAL DESIGN SUMMARY 


1.0 Introduction 

This design summary establishes the requirements for the performance, interface, 
design, quality assurance/reliability and safety of an Onboard Experiment Data 
Support Facility (OEDSF) . 

The purpose of the Onboard Experiment Data Support Facility is to process 
multiple sensor payloads data onboard the space shuttle to alleviate the ever- 
increasing cost of present processing schemes and to provide users with useful 
information of improved quality on a timely basis. In addition, the OEDSF is 
capable of effecting a bandwidth reduction via processing whenever possible. 

The OEDSF is configured to process multiple sensor outputs and the required 
ancillary data in real time or near real time. The facility is not restricted to 
any specific location or environment in the shuttle, and services instruments of 
multiple disciplines simultaneously. 


2 .0 Applicable Documents 

The following documents form a part of this design summary to the extent specified 
herein. In the event of conflict between documents in reference herein and the 
detail design requirements in the following sections, the detail design requirements 
supersede. In the event of conflict between documents in reference herein and 
lower tier references to documents in reference herein, the former supersede. 

National Aeronautics and Space Administration 

JSC 07700, Volume XIV, Rev. D, Space Shuttle System Payload Accommodation, 

NASA JSC, November 26, 1975. 

Spacelab Payload Accommodation Handbook, by NASA and European Space 
Research Organization, May, 1976. 

Safety Policy and Requirements for Payloads Using the National Space 
Transportation System, NASA Headquarters, Code MQ, June 1976. 

MIL-E-6Q51D (a3 amended for Space Shuttle Program), Electromagnetic 
Compatibility Requirement, Systems, June 4, 1973. 

MIL-STD-461A (as amended for Space Shuttle Program), Electromagnetic 
Interference Characteristics, June 4, 1973. 

S-311-P-11 Quality Monitoring of Integrated Circuits, 1 June 1970 

S-323-P-10 Commectors, Subminiature Electrical and Coaxial Contacts 
for Space Flight Use, Revised December 1969. 
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NHB 5300. 4(3A) 
NHB 5300. 4<1A) 
NHB 5300. 4(1B) 


Requirements for Soldered Electrical Connections May 1968 

Reliability Program Provisions for Space Systems Contractors 

Quality Assurance Program Provisions for Space Systems 
Contractors 


Military 


MXL-C-38999 

MIL-C-29012A 
MXL-C -26482 
MIL -C -17 
MIL-W-18Q44 
MIL-E-5400K 
MS33540C 
MIL-STD-454B 
MIL -STD -143 A 

MS -33586A 


Connectors, Electrical, Miniature, Quick Disconnect, 

Est. Reliability 

Connectors, Coaxial, RF, General Specification for 
Connectors, Electric, Circular, Miniature, Quick Disconnect 
Cables, RF, Coaxial, Dual Coaxial, Twin Conductors, Twin Lead 
Wire, Electric Cross-linked, Polyalkene, Insulated, Copper 
Electronic Equipment, Airborne, General Specification for 
Safety Wiring, General Practices 

Standard General Requirements for Electronic Equipment 

Specification and Standards, Order of precedence for Selection 
of, Change 1 

Metals, Definition of Dissimilar 


3 .0 Technical Requirements 

3.1 Functional Performance 

The basic 0EDSF is capable of receiving multiple sensor inputs in real time 
and processing the data to a specified level within the desired accuracy; 
i.e., multiple precision. The data inputs and outputs are asynchronously related 
to the OEDSF clock and are processed simultaneously without any form of off-line 
storage. Limited data buffers as required by the internal processing are 
provided . 

The OEDSF is readily reprogrammable to service different sets of sensors every 
too weeks . 
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The Onboard Experiment Data Support Facility possesses a growth potential and 
system efficiency through modularity. The OEDSF is a modular and programmable 
processor capable of being cascaded in depth and width without degradation of 
electrical parameters or throughput. 

The OEDSF is supplied 28 volts d.c. to 32 volts d.c. unregulated power 150 watts 
average for each array. The peak power requirement for the OEDSF does not 
exceed 180 watts. 

Thermal control of the OEDSF is by: (1) passive means such as thermal coatings, 

insulation, isolation and heat sink action of the OEDSF structures in conjunction 
with cold plates; and (2) by means of using built-in blowers and suitable gas; 
i.e., nitrogen. 

The OEDSF is capable of being fully configured and checked out 24 hours prior to 
launch before being installed in the Orbiter Processing Facility (OPF) , 


3 . 2 Data Proce: i ng Capabilities 

The OEDSF is a w. ,cband high speed programmable processor configured as a centralized 
facility capable of accommodating multiple sensor inputs from varied disciplines. 

The processor is capable of receiving sensor data asynchronously and transmitting 
data synchronously with the input. 

The OEDSF is capable of operating on sensors with a bandwidth of from a few bits 
per second to 120 megabits per second. It is capable of processing simultaneously 
the data of 20 average sensors and required ancillary data sources where the 
processing requirements of an average sensor are as shown in table 1. The OEDSF 
performs 10® operations for second as defined in tables 2, 3, and 4. The processor 
operates in real time without off-line storage. 


PARAMETER 

CHARACTERISTIC 

Frequency 

190 Kilobits per second 

Arithmetic Processes 

1160 per word 

Trigonometric Processes 

250 per word 

Exponential Processes 

40 per word 

Number of Channels 

10 

Word Size (Bits) 

12 

Buffer Size (Bits) 

93K 

Memory Size (Bits) 

13 IK 


Table 1 
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Typical arithmetic processes are shown in Table 2 . 


X+Y 

% (X+Y) 

X-Y 

•% (X-Y) 

X*Y 

~%F- (X*Y) 

X* Y"1 

“2KX-Y-1) 

x^i+z 

^(X-Y^+Z) 


Table 2 


Required trigonometric processes are shown in Table 3. 


Sin 

X 

Cos 

X 

Tan 

X 

Cot 

X 

Sec 

X 

Csc 

X 



Table 3 


Required exponential processes are shown in Table 4. 


In X 

e x 

y In X 

ye x 

xX 


Table 4 


The OEDSF is capable of processing 16 bit words with fixed point arithmetic 
in either one's complement or two's complement convention and at multiple precision. 

The OEDSF is characterized by a modular memory with the basic module capacity 
determined by Table 1. 

Signal Inputs . The OEDSF is capable of receiving positively asserted digital 
information and negatively asserted digital control signals in a bit serial/ 
word sequential format. The system is not capable of receiving analog signals 
or converting these signals from the analog to digital domain. 
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S ignal Outputs . The sytem outputs digital information synchronously with the input 
data in either word sequential/bit rial, word interleaved/bit serial, word 
sequential /bit parallel or word inter? eaved/bit parallel format with positive 
assertion. 

Signal Assertion . 

Positive Assertion 

Logical "one" 2.4 

Logical "zero" 0.2 

Negative Assertion 

Logical "one" 0.2 

Logical "zero" 2.4 


Volts to V cc 
Volts to 0.8 Volts 

Volts to 0.8 Volts 
Volts to V cc 


3.3 Power Supply 

The required power supply is provided as an integral part of the Onboard Experiment 
Data Support Facility. The power supply is a multiple output supply capable of 
accepting 28V d.c. to 32V d.c, with a peak power dissipation of 180 watts. 

The power supply provides the voltage regulation, SIX filtering, and power 
distribution for the 0EDSF. 

Harness interfaces for the Power Supply Subsystem are provided by the structures 
Subsystem for routing and mounting the spacecraft harness. 


3.4 Thermal Control 


Thermal Control Provisions maintains specified temperature levels and gradient-5 
for the OEDSF modules during all mission phases including pre-launch, launch, 
orbit, re-entry, and post landing. 

The OEDSF maintains component temperatures from +5°C to +35°C with a maximum 
average power dissipation of 150 watts. 

The OEDSF possesses thermal control provisions independent of the Shuttle 
except for energy to operate heaters. The subsystem is composed of both passive 
and active components as required. 


3.5 Mechanical Design 

The OEDSF is designed to withstand the following mechanical environments'. 


Stiffness . The structures subsystem provides adequate stiffness to satisfy 
the minimum frequency requirements . 

.Strength . The structures subsystem is designed to the qualification level 
quasisteady state accelerations of Table 5. Subsequent dynamic analyses will 
determine payload responses to the qualification vibration input test levels of 
Table 6. 

Acoustic . The structures subsystem is designed to the acoustic levels shown 
in Table 7. 

Shock . The structures subsystem is designed to the levels stated in the Space 
Shuttle System Payload Accommodations Document JSC -07700, VI, XIV. 


Table 5, Qualification Level Quasi-Steady State Accelerations 


Shuttle Mode 

Longitudinal 

fe's) 

Lateral 

. fe' s >. 

Liftoff 

-3.45 

12.25 

Orbiter End Bum 

-4.95 

-1.12 

Entry 

1.56 

3.75 

Landing 

±1.50 

4.2 

Crash (Forward) 

+9.0 

+4.5 

(Aft) 

-1.5 

-2.0 


Table 6, Sinsusoidal and Random Vibrations 


Sinusoidal Vibrations (g's) 

Random Vibrations (g's) 

Longitudinal 

TBD 

Lateral 

TBD 

t 

Frequency 

PSD (g 2 /Hz) 

°RMS 

Time 

(Sec) 

20 - 78 

78 - 300 
300 - 2000 ■ 

+3 dB/oet 
. ll dB/oct 
-3 dB/oct 

9.45* 

29* 


♦Levels under investigation and may be adjusted upward. 
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1/3-0CTAVE-8AND 
SOUND PRESSURE 
LEVELS (dB re 20/iN/m2) 


PREDICTED MAXIMUM ORBITER PAYLOAD BAY 
INTERNAL ACOUSTIC SPECTRUM 



FREQUENCY (Hz) 


Table 7 Internal Payload Bay Noise Estimates 




Ground Handling Transportation, and Storage . The structural design includes 
consideration of all environments to which the structure and its component 
parts are exposed during manufacture, ground handling, transportation and storage 
as stated in the Space Shuttle System Payloads Accommodations. Document JSC 07700, 
Vol. XIV. The OEDSF AGE is designed to support the OEDSF flight structure so 
as to preclude ground conditions from governing design of the flight hardware. 

Factors of Safet y. The design load factors of safety shown in Table 8 shall 
be applied to qualification loads presented in Table 5 to obtain the structural 
design yield and design ultimate loads. 

Margins of Safety . The structures subsystem shall maintain the minimum design 
margins of safety presented in Table 9. 

Margins of Safety less than 2.0 shall be indicated numerically. Those greater 
■than 2.0 shall be listed as high. 

The structure subsystem will be designed to mechanically interface with the 
following associated Aerospace Ground Equipment (AGE) and auxilliary Aerospace 
Equipment (AAE) ; (TBD) . 


Table 8 Design Load Factors of Safety 


Load Condition 


Launch (qualification level) 
Orbital (qualification level) 
System Qualification Test 
Transportation, Handling 


Design Load Factors of Safet 


Yield Ultimate 



Table 9. Margins of Safety 


Margins of Safety 


Fasteners in Shear 
Bolts in Tension 
Fittings 
Lugs 

Welds -Electron Beam 
Welds-Other 

Bonded Joints 


+.15 
+ .50 
+ .15 
+ .25 
+ .15 

+.50 (Dependent on Inspection 
Procedure) 

+ .50 


1 













